4 ms·

The notion that XML is difficult comes from the most profoundly lazy evaluations possible, where the most minimal of up front understanding are effort are esche

The notion that XML 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 launch mongodb and insert some giant mystery meat bags of json. We've seen this same mistake play out over, and over, and over again, and it is incredible that in a field where projects often end up taking thousands or more of man hours, people sweat and complain about 15 minutes up front gaining a basic understanding of a structure or API, and instead pursue solutions that, for instance, doesn't even have a date type or even consistent hack standard of how to handle it. This is how we have the rapid trends in this field, where the new panacea is tomorrow's nightmare.

stonogo 11y ago
This is the most breathtakingly ironic defense of XML I have ever seen.
- inversionOf 11y ago
  In what way is my post "ironic"? I would dearly love to know. Do you think my defense of XML is somehow that I am too lazy to know alternatives. You would be painfully wrong, dear friend, though such is a go to among the intellectually lazy (how many failed NoSQL projects were justified on notions of "people who criticize elements of it are just old and fear change". It's the laziest, most unprofessional retort possible, and fueled about a year of content on Hacker News, and was the meat of a million failed adventures) My post will be pummeled by the defensive, and that's okay.
  - stonogo 11y ago
    All of your invective was exactly what programmers were saying to XML proponents in the early days of XML. I still can't entirely tell if you're deliberately doing this or if you really are just wholly unaware of yourself. > 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
    - inversionOf 11y ago
      I recall approximately no one making that argument. That isn't to say there aren't terrible misuses of XML (the database within a database notion that, while sometimes necessary, is every beginner's mistake), but you're juxtaposing an absurd invention that isn't actually real at all. XML filled a role.
joepie91_ 11y ago
Was a reductio ad absurdum really necessary? 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.
- ralphm 11y ago
  The most valuable thing XMPP gains from using XML is namespaces. The way namespaces have been defined to work on top of XML, is what allows the protocol to be distributely extensible. I.e. anyone can define new protocol without having to clear this with a centralized body, not even the XSF. 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.
- inversionOf 11y ago
  Was a reductio ad absurdum really necessary? 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.
danbruc 11y ago
To add to this, it is hardly justified to compare XML and JSON - XML and the associated standards are a lot more powerful and feature-rich than JSON and the same holds for the available tools. JSON works well for simple things, XML proofs its usefulness when things become more complex. 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.
- joepie91_ 11y ago
  That's an important thing to note. The problem, however, is that a lot of people seem to be defending XML retroactively, because that's the choice that was made. An appeal to authority, if you will. 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.
nickpsecurity 11y ago
A Scheme Machine [1] with plenty code and hardware I just found: 60 pages 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. [1] https://www.cs.indiana.edu/ftp/techreports/TR413.pdf https://www.cs.indiana.edu/ftp/techreports/TR413.pdf [2] http://zserge.com/jsmn.html http://zserge.com/jsmn.html

stonogo 11y ago

This is the most breathtakingly ironic defense of XML I have ever seen.

inversionOf 11y ago
In what way is my post "ironic"? I would dearly love to know. Do you think my defense of XML is somehow that I am too lazy to know alternatives. You would be painfully wrong, dear friend, though such is a go to among the intellectually lazy (how many failed NoSQL projects were justified on notions of "people who criticize elements of it are just old and fear change". It's the laziest, most unprofessional retort possible, and fueled about a year of content on Hacker News, and was the meat of a million failed adventures) My post will be pummeled by the defensive, and that's okay.
- stonogo 11y ago
  All of your invective was exactly what programmers were saying to XML proponents in the early days of XML. I still can't entirely tell if you're deliberately doing this or if you really are just wholly unaware of yourself. > 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
  - inversionOf 11y ago
    I recall approximately no one making that argument. That isn't to say there aren't terrible misuses of XML (the database within a database notion that, while sometimes necessary, is every beginner's mistake), but you're juxtaposing an absurd invention that isn't actually real at all. XML filled a role.

joepie91_ 11y ago

Was a reductio ad absurdum really necessary? 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.

ralphm 11y ago
The most valuable thing XMPP gains from using XML is namespaces. The way namespaces have been defined to work on top of XML, is what allows the protocol to be distributely extensible. I.e. anyone can define new protocol without having to clear this with a centralized body, not even the XSF. 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.
inversionOf 11y ago
Was a reductio ad absurdum really necessary? 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.

danbruc 11y ago

To add to this, it is hardly justified to compare XML and JSON - XML and the associated standards are a lot more powerful and feature-rich than JSON and the same holds for the available tools. JSON works well for simple things, XML proofs its usefulness when things become more complex. 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.

joepie91_ 11y ago
That's an important thing to note. The problem, however, is that a lot of people seem to be defending XML retroactively, because that's the choice that was made. An appeal to authority, if you will. 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.

nickpsecurity 11y ago

A Scheme Machine [1] with plenty code and hardware I just found: 60 pages 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. [1] https://www.cs.indiana.edu/ftp/techreports/TR413.pdf https://www.cs.indiana.edu/ftp/techreports/TR413.pdf [2] http://zserge.com/jsmn.html http://zserge.com/jsmn.html