The Hidiocy of XML Languages

Bob Corrick 6 days later:

• • found your new home via Brad Appleton -> butunclebob

  • I wholeheartedly agree. Just ordered a book on ANTLR, to dip my toe in that water.

  • regards Bob Corrick Developer

Dean Wampler 11 days later:

• • I have this nutty idea that “scripting languages”, like Groovy, Ruby, etc. will largely supplant XML for everything non-trivial. So, you might still use XML for data, but you’ll use a mini-DSL in Ruby to express your business processes, etc.

Debasish Ghosh 13 days later:

• • How about s-exp instead of XML as program and data. I had blogged about this some time back (http://debasishg.blogspot.com/2007/05/xml-not-for-human-consumption.html).

Bill de hOra 14 days later:

• • At the top of your page:

  • html xmlns=”http://www.w3.org/1999/xhtml”

  • So yes; please stop writing in XML.

Andrei Pamula 14 days later:

• • ... or define a DSL in ruby, making use of real objects, make it user-friendly (ruby already is pretty :D). Now you can use any ruby editor in order to write specifications in your DSL.

  • Did I mention that you can now unit-test your DSL?

DAR 20 days later:

• • Ummm … has it ever occurred to anyone that there’s actually good reasons for writing file formats and protocols using XML??

  • First off, yes XML-based files/protocol streams need to be readable by humans, but only incidentally so. They’re primarily for communication between computers. Yes, occasionally people need to read them for debugging purposes and such, but that’s a secondary need. Given that, if the format is reasonably readable (i.e., text-based), that really is sufficient.

  • Secondly – and most importantly – the single, paramount, important reason why people base new things on XML is so that they can take advantage of standard tools to read/write these things. Why on earth should someone have to painstakingly craft a new grammar file from scratch (including minute details like what characters are allowable and where, how escaping will work, etc.) every time they need to create a new file format or protocol?? It makes zero sense. (Or, as you would put it, “This is just plain nuts, stupid, idiotic, retarded, poo-poo-headed, silliness!”) Surely leading members of the agile community can see the benefit of NOT REINVENTING THE WHEEL … several different times … on every project??!?

  • Third, you’re completely overlooking one incredibly important benefit of XML: XSLT. XML-based formats gain the huge benefit of having a preexisting analysis and transformation language available for it – completely for free! Want to analyze or filter your file or protocol stream? Easy! Just whip up a quick XSL file to do so. Want to transform your file or protocol stream into any other file format on earth? Again, piece of cake.

  • Helllllllooooooo wheel reinventors! Please paste this on your screen: “XML has a lot of benefits and will save me lots of time. It is not evil!”

Andy Glew 29 days later:

• • Yes, humans should never write directly in XML.

  • However, I agree with DAR: the advantage of XML is that standardized tools can manipulate it. I’ve written a lot of program analysis tools that have had to deal with the idiosyncrasies of C/C+, Perl, etc. – tools that are examining programs written in those languages. Or, rather, I’ve created klugey and fragile hacks – because it is pretty damned hard to find parsers for C/C+, or Perl, if you are not actually in a compiler team.

  • Consider SWIG, the interface and wrapper generator: it has to parse your C/C++ code. Started in 1996, even after 10 years it does not handle all of C++.

  • Obviously a compiler has to parse the language it is compiling. Tools like SWIG need to, as well. Obviously there should be a library that encapsulates the parsing, that can be shared between such tools, to avoid people having to write the parser again and again and again in different ways.

  • The best effort I have seen in this is GCC/XML. Its C/C++ parser is moe likely able to parse the whole language because it is the GCC parser. Unfortunately, it is forked and back versioned – so it does not support language features whose support was fixed or extended in later versions of GCC.

  • But anyway, my points are:

  • a) Parsing languages like C/C++ and Perl is hard.

  • b) Some tools need to do so.

  • c) If these languages can be translated to XML, it makes such tools easier.

  • OK, so that only means that I want a text-to-xml translator for languages such as C/C++.

  • But I can forsee the day when the language itself is defined in terms of XML. Humans would not write the XML, only tools and editors would…

  • Not only would such languages be easier to write tools for.

  • But such languages would also be easier to extend. E.g. consider that C and C++ diverged, in large part because many legal C programs are illegal C++ programs because C++ defined keywords that were legal C variable names. And nw the same thing is happening again, as C++ tries to add new keywords such as atomic, that used to be legal identifier names.

  • Any language that has a small set of keywords that would otherwise be legal identifiers is hard to extend.

  • Or, consider, C++ templates: which do you prefer, saying “typename Traits::int_type” all over the place? If you write lots of template could, it gets well nigh unreadable. But if it were – well, that is even more unreadable. But if your IDE hides the XML stuff, and just says “Traits::int_type” in some nice font and color?

  • XML languages suck.

  • But I expect there will be a new genheration of languages that do not look like XML, but which use underlying XML to distinguish keywords, types identifiers – to indicate language elements.

  • And I look forward to the program comprehension tools that such languages will facilitate.

  • In the meantime, I am looking for better tools such as GCC/XML.

Terence Parr about 1 month later:

• • Hi. You might enjoy my article called Humans should not have to grok XML.

  • Regards,

  • Terence