The author seems to be using "markup language" as a concept basically synonymous with a configuration language, or something that is not a programming language. A markup language is a language used to "mark up" text with formatting and structure. This may sound like a terminology nitpick, but I would argue the reason why for example XML is not a great configuration language is that it was designed to be something else – a markup language.
XML is a fantastic configuration language. Its primary purpose is text markup, right, but it can really shine as a configuration language too. It is meant to be used as a language, that is to describe structures of unbounded complexity while keeping them syntactically constrained.
The best configuration language is the one that is custom made for a specific application. A domain-specific language. But DSLs requires a parser and adding one is usually too cumbersome to merely parse a configuration. This is where XML comes in.
I think the author is probably aligning with "is" rather than "ought". So a language made this list if it IS being used as a configuration format, regardless of whether it OUGHT to be used as one.
Which is a way of deciding that makes sense given that I think the purpose of this article is "use my language instead". Getting lost in the weeds about each language's original design intent would bloat the article without meaningfully contributing to their thesis.
Given that it's an essential/definitional issue, I would have preferred that the author at least showed awareness of the differences between languages intended for marking up text and languages intended to represent data in a structured way.
Back when XML was first being developed, I was really anticipating having a standardized, easier-to-implement successor to SGML (which was hampered by its complexity and by the cost of the ISO standard) in the text markup space. It was that disappointing it ended up filling the vacuum in the space of serialized representations for for structured data, then getting rejected when it wasn't quite as suitable for that as alternatives such as JSON.
Me too, I still think it's cool. But while indeed easier-to-implement compared to SGML, it could have been yet a bit simpler. :) I once attempted to write a conforming parser, I remember it being a _lot_ of work to even determine well-formedness.
Ah, I was perhaps a bit unclear – I didn't mean to comment on whether certain languages made the list or not, I enjoyed the thorough walkthrough of languages being used for configuration.
I was more commenting on comments such as this one under Pkl:
> This is not a markup language. This is a full-blown programming language.
And under Nickel:
> Nice programming language. Not a markup language.
It's like he's saying "we should use markup languages for configuration, not programming languages", which I don't think he means.
I don't get why so many people hate XML. I'd rather us it than YAML.
I’ve often wondered the same. The op doesn’t go far beyond:
> The era of XML is in the past.
Which is about as deep as it seems to get. My suspicion is that the reason people don’t like it is because it’s a bit of a pain to work with in JavaScript
More generally XML is so thoroughly out of fashion that it is perceived as driving resume-driven architecture backwards in time, into an unfamiliar "dark age" of deliberate engineering decisions.
XML has a DOM API. And most people use JavaScript in a browser to manipulate the DOM. So I would say among all the language it should be the JavaScript devs that are the most proficient at the DOM API.
Once you have learned the DOM API, it’s pretty much universal. Things like Document.getElementsByTagName not only work in JavaScript but also in Python: https://docs.python.org/3/library/xml.dom.html#xml.dom.Docum...