SoylentNews is people
SoylentNews
Developer Tim Bray, of XML fame, has written an ode to The Sacred "Back" Button.
Younger readers will find it hard to conceive of a time in which every application screen didn't have a way to "Go Back". This universal affordance was there, a new thing, in the first Web browser that anyone saw, and pretty soon after that, more or less everything had it. It's a crucial part of the user experience and, unfortunately, a lot of popular software is doing it imperfectly. Let's demand perfection.
Why it matters · Nobody anywhere is smart enough to build an application that won't, in some situations, confuse its users. The Back option removes fear and makes people more willing to explore features, because they know they can always back out. It was one of the reasons why the nascent browsers were so much better than the Visual Basic, X11, and character-based interface dinosaurs that then stomped the earth.
Thus I was delighted, at the advent of Android, that the early phones had physical "back" buttons.
[...] Nowadays Android phones don't have the button, but do offer a universal "Back" gesture and, as an Android developer, you don't have to do anything special to get sane, user-friendly behavior. I notice that when I use iOS apps, they always provide a back arrow somewhere up in the top left corner; don't know if that costs developers extra work.
[...] People using your software generally have a well-developed expectation of what Back should do at any point in time, and any time you don't meet that expectation you've committed a grievous sin, one should remedy right now.
The undo function has been around since the beginning, though invented and reinvented several times. Some systems got it much later than others, but now its presence is universally expected.
(Score: 5, Insightful) by Anonymous Coward on Tuesday April 13 2021, @02:49AM (18 children)
Tim Bray's big achievement was unleashing XML on the world. He should be tried for crimes against humanity. It took many years for the programming community to admit the XML emperor had no clothes and was basically not good for anything, being inferior to just about any alternative. Thank God that mistake is behind us.
(Score: 2) by hendrikboom on Tuesday April 13 2021, @04:01AM (11 children)
One useful thing XML accomplished which others didn't was namespaces for tags.
The rest of the notation should have been accomplished more simply.
(Score: 4, Insightful) by Anonymous Coward on Tuesday April 13 2021, @05:18AM (9 children)
The only reason XML took off was because the web was taking off back then, and XML looked like HTML, and everyone thought HTML must be the future because that's what webpages were. I am serious, and it is just as dumb as it sounds. Using a text markup language as a data language--completely inappropriate paradigm. You're not marking anything up. XML has no support for basic data types like dictionaries or lists. JSON was the obvious successor that fixed the fundamental stupidity of XML.
(Score: 0) by Anonymous Coward on Tuesday April 13 2021, @05:25AM
Yeah just try to address the things people tried to do using regex D: my mind just melts when I see some of these shitpiles.
(Score: 5, Informative) by sjames on Tuesday April 13 2021, @05:41AM (2 children)
This exactly.
Then add all the marketing hype where people actually thought that two unrelated apps would magically inter-operate just because they both used XML. As if the industry hadn't JUST gotten over the idea that being CORBA compliant wouldn't, in fact, allow arbitrary unrelated apps to magically inter-operate.
Then they piled it deeper and claimed UML expressed as XML would magically allow the average PHB to produce clean working code! (seriously!) Personally, given a choice between that and monkeys with keyboards I would have bet on the monkeys.
(Score: 2) by digitalaudiorock on Tuesday April 13 2021, @01:46PM (1 child)
You know...all these same industry buzzword bullshit alarms go off every time I see anything about object storage. It's always struck me that storage should be dumb, and is arguably the last place you'd even want any of that bullshit. Yet just as with XML I tend to think there's a similar notion that just because an object has "intelligent metadata", everything in the world magically understands it. I think we've seen that movie before.
(Score: 2) by sjames on Tuesday April 13 2021, @08:33PM
Absolutely! It's not intrinsically a bad idea as a layer of a filesystem implementation (inode=object, extent=object), but the ways it will actually be marketed and used will certainly make a hash of it.
(Score: 3, Informative) by Anonymous Coward on Tuesday April 13 2021, @06:49AM (4 children)
Sure they can. Just add these to your DTD or translate to the appropriate schema:
<!ELEMENT dict (di*)>
<!ELEMENT di EMPTY>
<!ATTRLIST di key CDATA #REQUIRED>
<!ATTRLIST di value CDATA #REQUIRED>
<!ELEMENT list (li*)>
<!ELEMENT li (#PCDATA)>
(Score: 0) by Anonymous Coward on Tuesday April 13 2021, @12:49PM (1 child)
You are implementing dictionaries and lists in XML, but there is no native, dedicated syntax for them. That's a huge piece of critical, missing functionality in a data language. Scalars, dictionaries, and lists are about all you need!
(Score: 0) by Anonymous Coward on Tuesday April 13 2021, @08:58PM
I'm sorry, I misunderstood. What you really meant is that you needed TOOWTDI language instead of TMTOWTDI. Forcing your data into a predefined structure instead of using the structure already inherent in the data.
(Score: 2) by DannyB on Tuesday April 13 2021, @06:38PM (1 child)
Yes, that. Because of DTDs, when I edit various types of XML files, my IDE knows exactly what is allowed next. Any wrong tags or attributes are underlined in red . . . as I type.
If you think a fertilized egg is a child but an immigrant child is not, please don't pretend your concerns are religious
(Score: 0) by Anonymous Coward on Tuesday April 13 2021, @11:47PM
Oh you will love this new tool, it's called Clippy. Fixes your problems.
(Score: 0) by Anonymous Coward on Tuesday April 13 2021, @01:15PM
(Score: 2) by canopic jug on Tuesday April 13 2021, @06:40AM (1 child)
Yeah. Right. I can see documents, such as web pages, being done all in JSON.
Money is not free speech. Elections should not be auctions.
(Score: 1, Insightful) by Anonymous Coward on Tuesday April 13 2021, @07:05AM
The greatest strength of XML was its greatest weakness. It is too powerful and flexible. You can do almost anything with their schema when you move from DTDs to XSDs and beyond. The problem with that power and flexibility is that you had everybody reinvent the wheel and no real effort to come up with common schemas to allow easy interchange as originally imagined. Therefore, less powerful and simpler formats, like JSON, YAML, and more took over.
(Score: 2) by RamiK on Tuesday April 13 2021, @07:45AM (3 children)
DOM, DocBook, ePub, MusicXML...
The thing is, it's a really convenient prototyping tool. You can serialize pretty much any object-oriented data structure as is as if casting integers to floats without having to bother giving the file structure a second thought. People bring up .json, s-exp and .yaml as alternatives. They're right and they are better. But the whole point in choosing .xml is to temporarily put aside design considerations so you can focus on bugs and features that actually sell and later revisit that part of product.
The problem is the follow up where you're out of early development and suppose to finalize the specs and get a production ready file format to match but everyone are telling you that you have a working solution and it has all these great visualization tools that make pretty charts and are useful for debugging so why bother...
In the end you're left with a terrible but working solution. So to that effect, at least it's standardized and have libraries in every language so it's not as buggy as it could have been if every project would have baked their own.
And that right there is the story of every in tech.
compiling...
(Score: 2) by fadrian on Tuesday April 13 2021, @09:08AM (2 children)
You can serialize pretty much any object-oriented data structure as is as if casting integers to floats without having to bother giving the file structure a second thought.
You may not have noticed this, but OO is not what it used to be. It's now being seen as a swamp of unmanageable global state packed into object silos which can't easily be reasoned about. It will ultimately be subsumed by the functional programming paradigm just as OO superseded procedural program models - functional code is just that much easier to write/understand. And I say this as a programmer who cut his teeth on imperative programming languages and then moved to OO - from Smalltalk to cfront (Bjarne's first version of C++) to Java to Ruby and Python and just about everything in between. I've now moved on to functional languages - Clojure, F#, and Haskell - and can say that the code in this space is much better - easier to write, more generic, and usually thread-safe without all the complicated mechanisms of doing that in OO. So pointing out that anything was great for OO is like pointing out technology that was great for large prop planes in the early days of jets - interesting, but in the long run, irrelevant.
That is all.
(Score: 1, Insightful) by Anonymous Coward on Tuesday April 13 2021, @09:41AM
object-oriented data structures != object-oriented programming paradigm
Just because your data structure is object-oriented does not mean you have to use an OOP language and just because you are using an OOP language does not mean you have to use an object-oriented data structure. Some things are easier to think about as objects with attributes or are objects with attributes, so it is just easier to keep the data structured that way. Other things are not objects with attributes or are difficult to think of that way, so it is just easier to structure data in a different way. That's all that means. You are free to program around them however you please. For example, you can do object-oriented data structures in Haskell just fine, but they aren't objects in the OOP sense; and you can do non-object-oriented data structures in Smalltalk, but they are still objects in the OOP sense.
(Score: 4, Interesting) by RamiK on Tuesday April 13 2021, @11:20AM
When protoyping I want my code easy to write and generic. When debugging I want my code easy to read and as explicit, imperative and static as C so I won't have to stop and think if everything going in and out is per expectations.
I believe what we actually want is a language that can be "compressed" into generics and state machines and "decompressed" out of generics losslessly without losing variable and function names and looking like assembly out of a debugger. Something akin to classroom java workflow where you're glued to the debugger since it's not clattered, only with actual editable code instead of looking at a stack.
I know there's a lot of hard problems and limitations for this sort of "specs". But nevertheless, I reckon a dual-language such as this will be a great generic language that you'd then embed some C and such in for the performance parts.
compiling...