Live data from Hacker News

XML is a cheap DSL

unplannedobsolescence.com

31–40 of 274 posts

Re: XML is a cheap DSL

#31
post #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. app…

Suggest to Raku to that list. All the early Raku devs were Haskell coders (the first Raku parser (PUGS) was written in Haskell).

Since Raku suports both OO and Functional coding styles, and has built in Grammars, it is very nice for DSLs.

Re: XML is a cheap DSL

#32

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" } }…

YAML seems like a great middleground here between xml and json..

YAML is never a great anything.

Re: XML is a cheap DSL

#34
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 ofte…

The 'much harder for programmers to work with' was that the official way of doing a lot of programming related to XML was to do it in... XML. E.g. transformations were done with XSLT, query processing with XQuery. There were even XML databases that you had to query with XML (typically XQuery).

All these XML DSLs were so dreadful to write and maintain for humans that most people despised them. I worked in a department where semantic web and all this stuff was fairly popular and I still remember remember one colleague, after another annoying XML programming session, saying fuck this, I'll rip out all the XSLT and XQuery and will just write a Python script (without the swearing, but that was certainly his sentiment). First it felt a bit like an offense for ditching the 'correct' way, but in the end everyone sympathized.

As someone who has lived through the whole XML mania: good riddance (mostly).

And don't even get me started on the endless meetings of people trying to design their XML schemas.

I have found that this attracts certain type of people who like to travel to meetings and talk about schemas and ontologies for days. I had to sit through some presentations, and I had no idea what they presented had to do anything, they were so detached from reality that they built a little world on their own. Sui generis.

Re: XML is a cheap DSL

#35
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…

While this can give a notation for the domain, you'd still need an engine to process it. Prolong+CLPFD perhaps meets it well (not too familiar with the tax domain) and one could perhaps paraphrase Greenspun's tenth rule to this combo too.

Re: XML is a cheap DSL

#37
It's not a DSL. It's a generic lexer and parser. It takes the text and gives you an abstract syntax tree. The actual DSL is your spec, and the syntax you apply.

It's one of many equivalent such parser tools, a particularly verbose one. As such it's best for stuff not written by hand, but it's ok for generated text.

It has some advantages mostly stemming from its ubiquity, so it has a big tool kit. It has a lot of (somewhat redundant) features, making it complex compared to other options, but sometimes one of those features really fits your use case.

Re: XML is a cheap DSL

#38
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'm not sure what the author means by "(XML) was abandoned because JavaScript won. The browser won."

The browser supported XML as much as Javascript. Remember that the "X" in "AJAX" acronym stands for XML, as well as "XMLHttpRequest" which was originally intended to be used for fetching data on the fly in XML. It was later repurposed to grab JSON data.

Javascript was not a reason XML was abandoned. It was just that the developer community did not like XML at all (after trying to use it for a while).

As for whether the dev community was "right", it's hard to comment because the article you linked is heavy on the ranting but light on the contextual details. For example it admits that simpler formats like JSON might be appropriate where "small data transfers between cooperating services and scenarios where schema validation would be overkill". So are they talking about people storing "documents" and "files" in JSON form? I guess it happens, but is it really as common to use JSON as opposed to other formats like YAML (which is definitely not caused by Javascript in the browser winning)?

Personally I think XML was abandoned because inherent bad design (and maybe over-engineering). A simpler format with schema checking is probably more ideal IMHO.

Re: XML is a cheap DSL

#39
It kinda blows my mind that after XML we've managed to make a whole bunch of stuff that's significantly worse for any serious usage.

JSON: No comments, no datatypes, no good system for validation.

YAML: Arcane nonsense like sexagesimal number literals, footguns with anchors, Norway problem, non-string keys, accidental conversion to a number, CODE INJECTION!

I don't know why, but XML's verbosity seems to cause such a visceral aversion in a lot of people that they'd rather write a bunch of boring code to make sure a JSON parses to something sensible, or spend a day scratching their head about why a minor change in YAML caused everything to explode.

Actually my own problem with XML was annoyance that back when I had the thought of doing a complex config format in XML, the idea of modifying it programmatically while retaining comments turned out to be absolutely non-trivial. In comparison with the mess one can make with YAML that's just a trivial thing.

Re: XML is a cheap DSL

#40

Earlier quoted context omitted.

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 ofte…

Since you explicitly mentioned fashion, I assume you read this: > There is a distinction that the industry refuses to acknowledge: developer convenience and correctness are different concerns. They are not opposed, necessarily, but they are not the same thing. … The rationalization is remarkable. "JSON is simpler", they say, while maintaining thousands of lines of validation code. "JSON is more readable", they claim,…

In your situation, I would blame the developers, not the tools (JSON) or fashion.

Even if it's fashionable to do the wrong thing, the developer is at fault for choosing to follow fashion instead of doing the right thing.

Post reply on HN