Live data from Hacker News

XML is a cheap DSL

unplannedobsolescence.com

11–20 of 274 posts

Re: XML is a cheap DSL

#11
post #6

While a great article, I actually found this linked post [0] to be even better, in which the author lays out how so much modern tooling for web dev exists simply because XML lost the browser war. EDIT: obviously, JSON tooling sprang up because JSON became the lingua franca. I meant that it became necessary to address the shortcomings of JSON, which XML had solved. 0: https://marcosmagueta.com/blog/the-lost-art-of-xml…

I read both, but I feel like they both miss what it was like to work with APIs back in the bad old XML days.

Yes, XML is more descriptive. It's also much harder for programmers to work with. Every client or server speaking an XML-based protocol had to have their own encoder/decoder that could map XML strings into in-memory data structures (dicts, objects, arrays, etc) that made sense in that language. These were often large and non-trivial to maintain. There were magic libraries in languages like Java and C# that let you map XML to objects using a million annotations, but they only supported a subset of XML and if your XML didn't fit that shoe you'd get 95% of the way and then realize that there was no way you'd get the last 5% in, and had to rewrite the whole thing with some awful streaming XML parser like SAX.

JSON, while not perfect, maps neatly onto data structures that nearly every language has: arrays, objects and dictionaries. That it why it got popular, and no other reason. Definitely not "fashion" or something as silly as that. Hundreds of thousands of developers had simply gotten extremely tired of spending 20% of their working lives producing and then parsing XML streams. It was terrible.

And don't even get me started on the endless meetings of people trying to design their XML schemas. Should this here thing be an attribute or a child element? Will we allow mixing different child elements in a list or will we add a level of indirection so the parser can be simpler? Everybody had a different idea about what was the most elegant and none of it mattered. JSON did for API design what Prettier did for the tabs vs spaces debate.

Re: XML is a cheap DSL

#13
post #7

XML is notoriously expensive to properly parse in many languages. Basically, the entire world centers around 3 open source implementations (libxml2, expat and Xerces), if you want to get anywhere close to actual compliance. Even with them, you might hit challenges (libxml2 was largely unmaintained recently, yet it is the basis for many bindings in other languages). The main property of SGML-derived languages is that…

> and have two axes for adding metadata: one being the tag name, another being attributes

Yes let's not even get started on implementations who do

Re: XML is a cheap DSL

#14
post #4

Given that that is had strong schema XSD verification built in, where you can tell in an instant whether or not the document is correct; it’s the right tool for a majority of jobs. My experience has been the people complaining about it were simply not using automated tools to handle it. It’s be like people complaining that “binaries/assembly are too hard to handle” and never using a disassembler.

what jobs require XSD verification?

Re: XML is a cheap DSL

#15
Or... you could just use a programming language that looks good and has great support for embedded domain-specific languages (eDSL), like Haskell, OCaml or Scala.

Or, y'know, use the language you have (JavaScript) properly, eg. add a `sum` abstraction instead of `.reduce((acc, val) => { return acc+val }, 0)`.

In particular, the problem of "all the calculations are blocked for a single user input" is solved by eg. applicatives or arrows (these are fairly trivial abstract algebraic concepts, but foreign to most programmers), which have syntactic support in the abovementioned languages.

(Of course, avoid the temptation to overcomplicate it with too abstract functional programming concepts.)

If you write an XML DSL:

1. You have to solve the problem of "what parts can I parallelize and evaluate independently" anyway. Except in this case, that problem has been solved a long time ago by functional programming / abstract algebra / category-theoretic concepts.

2. It looks ugly (IMHO).

3. You are inventing an entirely new vocabulary unreadable to fellow programmers.

4. You will very likely run into Greenspun's tenth rule if the domain is non-trivial.

Re: XML is a cheap DSL

#17
post #4

Given that that is had strong schema XSD verification built in, where you can tell in an instant whether or not the document is correct; it’s the right tool for a majority of jobs. My experience has been the people complaining about it were simply not using automated tools to handle it. It’s be like people complaining that “binaries/assembly are too hard to handle” and never using a disassembler.

what jobs require XSD verification?

Ideally all of them.

Re: XML is a cheap DSL

#18
Sometimes I wonder why we need to invent another DSL. (or when should we?)

At work, we have an XML DSL that bridges two services. It's actually a series of API calls with JSONPath mappings. It has if-else and goto, but no real math (you can only add 1 to a variable though) and no arrays. Debugging is such a pain, makes me wonder why we don't just write Java.

Re: XML is a cheap DSL

#19
S-expressions are a cheap dsl too. I use it in my desktop browser runtime that is powered by wasm that I’m developing As the “HTML”^1 and CSS^2 in fact it works so well I use it also reused it to do the styling for html exports in my markup language designed to fight documentation drift^3.

1. https://gitlab.com/canvasui/canvasui-engine/-/blame/main/exa...

2. https://gitlab.com/canvasui/canvasui-engine/-/blob/main/exam...

3. https://gitlab.com/sablelang/libcuidoc

Re: XML is a cheap DSL

#20
At the cost of a slightly more complex schema, the JSON representation can be made much more readable:

    {
      "path": "/tentativeTaxNetNonRefundableCredits",
      "description": "Total tentative tax after applying non-refundable credits, but before applying refundable credits.",
      "maxOf": [
        {
          "const": {
            "value": 0,
            "currency": "Dollar"
          }
        },
        {
          "subtract": {
            "from": "/totalTentativeTax",
            "amount": "/totalNonRefundableCredits"
          }
        }
      ]
    }
Post reply on HN