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.
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’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
In the world of human-readable data formats (ie not programming languages), the best one I ever used was Jane Street's sexplib[1] s-expression format.
It was concise and expressive. There was a direct way to describe variants (types with multiple constructors), which is always awkward in JSON, but the format was still surprisingly low-noise for reading and editing by hand. I remember you could even use it as a lightweight markup format:
(here is some text with (em formatting) information)
(The format leaves the interpretation of things like (em ...) up to you; you could use it as a slightly more verbose Markdown, but you could also use it to structure readable text with other sorts of metadata instead.)
And, unlike certain other formats I won't name, it has comments!
It also helps that Emacs with Paredit makes editing s-expressions flow. The tool doesn't need to know anything about the sexplib format specifically; just relying on basic s-expression structure gives us fluid but simple structural editing.
I am constantly sad that nobody else uses this sort of format, and I have to deal with a mixture of JSON, YAML, TOML and other ad-hoc formats instead.
Agree, sexp is quite nice. That was my favorite before json came around. Not that I like json particularly, it just ate the world so it's easier to go along with it.
No mention of The Configuration Complexity Clock [1] which I always think deserves a link, but credit to the author for actually keeping it slim and readable over (IMHO) most of the newer additions to the landscape which either declare themselves as 'obvious' and aren't or just add features such as Pkl's extends keyword, moving us further round the complexity clock.
Of course just adding multiline strings is the start of the rabbit hole, now you need to think about leading line breaks, trailing line breaks, intermediate line breaks, whitespace chomping, and- oh heavens I've reinvented YAML, I think I need to lie down.
One kinda-exception I'd like to raise: Cases where you'd like to use the regular proper programming language from the very beginning, but there are trust issues, and there's no good/reliable sandboxing option.
For example, B2B stuff where every customer has their own idiosyncratic sets of rules for if-this-then-that, which change at a different cadence than your releases.
In those cases, it's less that configuration slowly becomes too complex and evolves into code, and more that code is wanted from the get-go but configuration is the compromise.
Just to ensure you're aware: This is why Google made Starlark. You can think of it as just enough Python for the exact use case you talked about. Deterministic + hermetic is great.
Nice article. I've definitely moved the clock to 6.
And I remember toying with the idea of 9 but I think for a different purpose, I don't remember what. Never did get that far though, I'm acutely aware that tooling is also important, but it's still oh-so-tempting.
I wonder where the company is at now. I don't think they would have moved the clock ahead but they may have moved it backwards to 12.
I don't regret my little rules engine though. It held up very well. It was intended for non-devs to be able to use, but the article is quite right, a complex set up was not easy to understand! I often got questions when things looked wrong but after much thinking the rules were usually calculating things correctly.
The alternative would have been 100 hardcodings because each client needed something different.
I don't like this article all that much but I do like the MAML format the author wrote this to promote. It seems like it’s everything that’s good about JSON, plus everything fixed for human writing, and nothing more.
Hats off, wish my package.json and build.yml were package.maml and build.maml.
It’s not a sufficient improvement over JSON for it to be worthwhile.
The configuration languages that are truly worthwhile are the ones that the author deride as being too similar to programming languages, like Jsonnet, Starlark, CUE, and Dhall (in increasing order of worthwhileness).
MAML is an improvement from JSON, but does not improve the data types much (although it does make one improvement, which is that it distinguishes integers from floating point), although the syntax is improved.
Shallow. Especially “ The era of XML is in the past… now it's dead.”
That’s not an argument against the merits of XML, it’s just a fashion declaration.
It’s also wrong. Podcasting boils down to XML files. It even heavily uses XML’s extension mechanism. XML is the basis for RSS and Atom. XML is the basis for LibreOffice and modern Microsoft Office files. XML is at the core of the epub digital book standard. And on and on.
XML may not be ideal for config (reasonable people can disagree on the topic) but it’s not dead.
It’s also interesting that he declares JSON “won” then adds a bunch of XML features to it like ordered entries and not having to quote element/attribute names.
JSON “won” for web apis - e.g. browser-server data interchange. It is not, and was never claimed to be, good for serial documents like config, or for when you need an extensible format (the “X” in XML). It’s fine for what it is, and so is XML, which, when it “won”, was similarly overused, like for web apis.
FWIW, JSON with `#` comments and redundant comma before `}` and `]` is already supported by many programming languages, e.g., Perl's JSON module (the 'relaxed' option). The advantage is that correct JSON also works, i.e., that JSON module just make it less error prone for humans, but otherwise sticks to the existing format.
> This is why I based my MAML on top of JSON. I fixed things that were a little bit annoying for me inside JSON.
And now it's incompatible with JSON, which is the worst part of the idea.
Instead, maybe propose a patch to your favorite programming language's JSON module to accept the same extensions for humans that the Perl module already supports, and maybe someone uses it for their JSON config files. This moves us together instead of further apart.
> Well, this is some sort of programming language with dynamic types. But there are so many good programming languages, so I don't know why this one needs to be used.
RE: Jsonnet and others: because it has nice guarantees, like lack of arbitrary I/O and pure execution.
I wonder if "the right solution" is a programming language that is fast, concise, trivially easy to run, and outputs some efficient binary format like protobuf.
Programming languages have comments and control flow, multiple popular implementations, and can have nice literals. Lack of Turing completeness is actually not a terribly useful feature if you trust the input (and you should probably just use protobufs or similar for untrusted inputs in that case.)
I do not want control flow of any kind in my configuration file. Nor do I want expressions or any kind of evaluation.
Greppability is a must-have feature for me. As is simplicity - I don’t want to have to deal with internalizing interpreter mechanics, rules for precedence, variable scope, etc just to figure out what config values my program is going to be provided with.
Any time I’ve been forced to work with a system which used a general or restricted programming language to express configuration, it’s been a nightmare.
If your config language doesn't have its own control flow then it's going to get a meta layer added on with control flow. Like, what do you do if this service has a different hostname in staging versus prod? Or connects to a different DB, or whatever. Either have one template file and give it a values file when you go to deploy it, or have two fully-written out files... which becomes annoying when you have to make sure you keep them in sync across two or more environments, often leading to a hacked on and poorly implemented templating system anyway (eg, Helm)
Readit News
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.
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.
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.
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.
> 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
It was concise and expressive. There was a direct way to describe variants (types with multiple constructors), which is always awkward in JSON, but the format was still surprisingly low-noise for reading and editing by hand. I remember you could even use it as a lightweight markup format:
(The format leaves the interpretation of things like (em ...) up to you; you could use it as a slightly more verbose Markdown, but you could also use it to structure readable text with other sorts of metadata instead.)And, unlike certain other formats I won't name, it has comments!
It also helps that Emacs with Paredit makes editing s-expressions flow. The tool doesn't need to know anything about the sexplib format specifically; just relying on basic s-expression structure gives us fluid but simple structural editing.
I am constantly sad that nobody else uses this sort of format, and I have to deal with a mixture of JSON, YAML, TOML and other ad-hoc formats instead.
[1]: https://github.com/janestreet/sexplib
Of course just adding multiline strings is the start of the rabbit hole, now you need to think about leading line breaks, trailing line breaks, intermediate line breaks, whitespace chomping, and- oh heavens I've reinvented YAML, I think I need to lie down.
[1] https://mikehadlow.blogspot.com/2012/05/configuration-comple...
For example, B2B stuff where every customer has their own idiosyncratic sets of rules for if-this-then-that, which change at a different cadence than your releases.
In those cases, it's less that configuration slowly becomes too complex and evolves into code, and more that code is wanted from the get-go but configuration is the compromise.
https://starlark-lang.org/
So Varnish Configuration Language? It's definitely an awkward case that doesn't seem to fit neatly into the landscape.
And I remember toying with the idea of 9 but I think for a different purpose, I don't remember what. Never did get that far though, I'm acutely aware that tooling is also important, but it's still oh-so-tempting.
I wonder where the company is at now. I don't think they would have moved the clock ahead but they may have moved it backwards to 12.
I don't regret my little rules engine though. It held up very well. It was intended for non-devs to be able to use, but the article is quite right, a complex set up was not easy to understand! I often got questions when things looked wrong but after much thinking the rules were usually calculating things correctly.
The alternative would have been 100 hardcodings because each client needed something different.
Hats off, wish my package.json and build.yml were package.maml and build.maml.
The configuration languages that are truly worthwhile are the ones that the author deride as being too similar to programming languages, like Jsonnet, Starlark, CUE, and Dhall (in increasing order of worthwhileness).
That’s not an argument against the merits of XML, it’s just a fashion declaration.
It’s also wrong. Podcasting boils down to XML files. It even heavily uses XML’s extension mechanism. XML is the basis for RSS and Atom. XML is the basis for LibreOffice and modern Microsoft Office files. XML is at the core of the epub digital book standard. And on and on.
XML may not be ideal for config (reasonable people can disagree on the topic) but it’s not dead.
It’s also interesting that he declares JSON “won” then adds a bunch of XML features to it like ordered entries and not having to quote element/attribute names.
JSON “won” for web apis - e.g. browser-server data interchange. It is not, and was never claimed to be, good for serial documents like config, or for when you need an extensible format (the “X” in XML). It’s fine for what it is, and so is XML, which, when it “won”, was similarly overused, like for web apis.
Deleted Comment
> This is why I based my MAML on top of JSON. I fixed things that were a little bit annoying for me inside JSON.
And now it's incompatible with JSON, which is the worst part of the idea.
Instead, maybe propose a patch to your favorite programming language's JSON module to accept the same extensions for humans that the Perl module already supports, and maybe someone uses it for their JSON config files. This moves us together instead of further apart.
RE: Jsonnet and others: because it has nice guarantees, like lack of arbitrary I/O and pure execution.
See: https://sre.google/workbook/configuration-specifics/#pitfall...
Programming languages have comments and control flow, multiple popular implementations, and can have nice literals. Lack of Turing completeness is actually not a terribly useful feature if you trust the input (and you should probably just use protobufs or similar for untrusted inputs in that case.)
I do not want control flow of any kind in my configuration file. Nor do I want expressions or any kind of evaluation.
Greppability is a must-have feature for me. As is simplicity - I don’t want to have to deal with internalizing interpreter mechanics, rules for precedence, variable scope, etc just to figure out what config values my program is going to be provided with.
Any time I’ve been forced to work with a system which used a general or restricted programming language to express configuration, it’s been a nightmare.