> XML is unnecessarily complex for this kind of usecase, and too hard and time-consuming to work with (and I agree)
What is 'difficult' in XML?
What is 'difficult' in XML?
JSON can be very easily natively represented in just about any language: you have objects/hashmaps/dicts, arrays, booleans, strings, numbers, and null. This means that accessing something in a JSON object is simple - you just use standard member access in your language of choice.
XML is considerably harder to use - you have children, and attributes. You have namespaces, and so on. These make it impossible to use a basic 'data model' like for JSON - instead you need interactive objects, that let you traverse the tree.
You can no longer simply map/filter/reduce over data. You can't easily access deeply nested structures without lots of syntax clutter. You can't easily serialize back and forth. Instead of using what your language already provides for data structures, you now need to learn an entirely new one, specifically for XML.
That is what is 'difficult' in XML - it considerably increases the cognitive load for working with it. You can't keep the structure in your head easily, but need to look at documentation instead, and need to learn a specific (often bulky!) API just to interact with the data.
Realistically, XML is useful for storage of complex data, but you really shouldn't be using it for wire serialization like XMPP does. XML is useful in a small subset of usecases, and trying to apply it to everything else is a mistake.
This makes it possible to experiment over the live xmpp network.
map/filter/reduce etc is possible with XML. Scala does it. Other languages can do it to. It's purely depending on your language. Even JavaScript has better XML support than the language you're portraying here :-)
Sure. The problem is that in every implementation I've seen, they're unreasonably hard to work with. Giving each extension its own key in a JSON object accomplishes the same, without breaking the native data model.
> map/filter/reduce etc is possible with XML. Scala does it. Other languages can do it to. It's purely depending on your language. Even JavaScript has better XML support than the language you're portraying here :-)
Yes, it's possible, but it's too hard. It always introduces more complexity when compared to standard deserialized JSON (in any language that can natively represent the JSON data types, which seems to be most).
Just like Generics.
Java, for example, does support Optional types similar to Haskell’s Maybe.
Haskell in supports them, too
No, it's not the biggest challenge but it's so transparently a case of conplete disregard for developer productivity that I've heard it mentioned by a lot of people as why they avoid XML.
This is the core issue with XML/XMPP. UX simply doesn't seem to have ever been a factor when designing either of them - whether towards the developers or the end users.
(XMPP would've used JSON had it existed in 1998, fwiw.)
The web is a lot of things, but broad consumer adoption of web technology also involves boring things like banks. SOAP and WSDL weren't created in a vacuum. They exist because Java / XML made it even possible to bridge the gap from the old world.
As much as we like all sorts of features of the web, integrating commerce was what brought the enterprise in, drove down costs, etc etc etc.
Yes – in particular, I remember liking the initial promise of XML 1.0 and then being disappointed as the initial simplicity was buried under layers of gratuitous complexity as the enterprise computing crowd jumped on board. Some neat ideas (e.g. XPath)
Similarly, my first database-backed web app was a Java servlet in 1996. I assumed it would become richer in the future but it was still pretty easy write and deployment was pretty simple at that point. Instead, the community chased off after more complexity (JavaBeans, the near-pervasive obsession with runtime configuration and the ensuing massive config files, nested abstraction layers, etc.) rather than focusing on basic developer productivity. We got massive piles of code like RMI (i.e. CORBA) before basic features like regular expressions, logging, etc.
> Could we have built anything on the scale of the web with CORBA?
No. We also failed, repeatedly, to do it with XML for reasons which are obvious to anyone who's ever used SOAP/WSDL/etc.
The common theme was seeing complexity and, especially, abstraction as a universal good rather than something with real costs and forgetting how important high-quality implementations are, particularly when you're relying on them to help with all of that complexity.
Rich Hickey did a great service outlining some common problems when thinking about the word complexity itself: http://www.infoq.com/presentations/Simple-Made-Easy
I don't think it's about the engineers wanting to see complexity, so much as the problems you mention stemming from design-by-committee.
And yes, you absolutely do have to use namespaces when working with a third-party protocol that chooses to use them. You can't opt out.
This is how we have the rapid trends in this field, where the new panacea is tomorrow's nightmare.
My post will be pummeled by the defensive, and that's okay.
> The notion that binary serialization is difficult comes from the most profoundly lazy evaluations possible, where the most minimal of up front understanding are effort are eschewed if you can just open a text file and insert some giant mystery meat bags of XML.
etc etc
The significance of cognitive load in software development is well-understood, so it seems you're barking up to the wrong tree.
Yes, making things 'simpler' at the cost of architectural issues is bad - but that does not give you a wildcard to claim that complexity doesn't matter, as you seem to be doing right now.
A protocol like XMPP could easily use JSON without any significant architectural issues resulting from it.
Screaming "get off my lawn" to anybody who cares about developer efficiency, without any rational arguments underlying it, is not going to encourage them to use XMPP. It will just make them see you as a hostile dick that they don't want anything to do with. And that is not an insult - that is the reality of how people interpret these kind of posts.
If you'd want this property in a JSON-based wire protocol, you'd invariably going to end up with XML-in-curly-brackets. This is why developing with/for XMPP is slightly harder than a protocol that has a limited feature scope.
However, as Dave mentions elsewhere, one shouldn't have to deal with the wire protocol directly to use XMPP in your application. A proper library should abstract from that. Arguably in some platforms, that's still a weak spot.
Yet there was none. Your very post, though, not only attempts to paint my comment as an "old person thing" (hilariously), it then attacks the speaker ("hostile dick"). Before you (incorrectly) start claiming fallacies, maybe commit to witholding them yourself.
My comment absolutely rises defensiveness among some people. But this is an endemic issue in this industry, and your personal feeling of diminished professionalism in the face of it needn't merit attack responses -- countless projects chose technologies not because they were efficient in any real world sense of that word (saving 15 minutes on the first day to pay thousands of hours later is hardly anyone's measure of "efficiency", and that you attempt to attack the very clear statement I made boggles the mind), but because they were the laziest, most accessible option available, saving a tiny amount of effort at the forefront.
Generating code is easy. Generating tonnes of code is easy. Generating good, well considered solutions, learning and adopting appropriate technologies and choices...well that's hard.
There was. You were painting an overly ridiculous consequence of the argument, and then arguing against that overly-ridiculed consequence.
> Your very post, though, not only attempts to paint my comment as an "old person thing" (hilariously), it then attacks the speaker ("hostile dick").
As I explicitly pointed out, that wasn't an insult. It was a pointer as to how other people will likely interpret your comment. Which was more or less confirmed by the downvotes on it.
I wasn't attacking you. I was trying to make you understand how other people would read your comment.
The rest of your post again uses an overly ridiculous version of the argument to argue against (that really has nothing to do with my original statement), so there's really not much point in me responding to that.
By the way, XMPP predates JSON or at least stems from a time when JSON was not jet standardized or widely accepted, so at least in the context of XMPP the XML vs JSON debate is pretty futile to begin with.
Realistically, it's completely understandable that XMPP was built on XML, and it made perfect sense at the time - but that should not preclude us from acknowledging that there are serious usability issues with it.
The R5RS Scheme specification w/ example code: 50 pages
XML 1.0 specification for structure only: 49 pages
Sun's efficient, binary XDR: 29 pages
Wirth's Oberon Programming Language spec: 21 pages
ECMA JSON specification: 14 pages
Jsmn - portable, JSON parser [2] in C: 7 pages
I'm sure the above illustrates quite well how difficult and complex XML is. Additionally, while students everywhere implement LISP, there's a whole chapter in Beautiful Code where writing a good XML parser is an accomplishment people pay to see. Far from minimal understanding, reading XML's specification is a HOW-TO guide for how non-programmers that haven't seen superior works (eg Scheme, Oberon) try to handle data management. It was horrible, I used s-expressions/XDR instead, and implemented whole thing in a few hundred lines of straight-forward code. Best of all, unlike XML, my code could've run through a tool to prove it free of the types of bugs hackers love to exploit.
So, there's my proof that XML is garbage. Essentially everything it does can be done better by using one or more tools with less complexity, more cost-effectiveness, and more straight-forward implementation. Nobody should waste time learning it. If work demands, they should just learn a library that handles the awful details for them and internally use something else. Also, they should avoid any protocol that depends on it: that's just bad design.