I couldn't help but notice almost immediately one feature that is not human oriented, but most likely exists because it's easier for a machine to parse: single (":") vs double colon ("::"). This is not human-friendly. A human wants to write "key" "is" "value", and YAML has for a very long time supported a single ":" for "is" regardless of the actual type of the value.
I shouldn't have to care about what the type of the value is when writing out effectively YAML. This double-colon feature will do nothing but lead to bug reports from people confused as to why their document is invalid.
In my theory of "human-readability", odd double tokens like :: can exist successfully so long as there is sufficient utility and logic in the single token :
Tokens are inseparable from human instincts of single = less, double = more and the corresponding emotions: single=less=easier=quicker, double=more=complicated=longer=difficult
If you are not emphasizing the single token as them most common, it's going to cause confusion.
This is the main reason why YAML and Python are bad. Give us CLEAR beginnings and ends to code statements and blocks, not these dubious beginnings and ends. Ignore white space and use clear EOL delineation. Clearly, XML and JSON are superior to YAML and even this weird-looking HUML. Not to mention almost any other language syntax being superior to Python.
I have actually practically tried out a test where I give a huge config file in XML and then JSON and ask folks question on its structure.
The ones who read the XML file understood immediately. Why ? Because XML is self-documenting and the repetition via clear de-limitation extensively aids human memory.
The one who read the JSON file just glazed over it and needed to refer back to the document and re-read several times.
I urge all the XML naysayers and XML haters to please carry out this practical test with their colleagues. Please choose a good level of complexity and nesting and please make use of XML attributes for scalar values.
XML is SO FAR ahead in readability and grokking that it is not funny.
Exactly. And with a proper color scheme it is so much easier to "parse" a document as a human.
But JSON popularity is linkend to the web and javascript so not much that can be done.
Coming up with new ambiguous markups just for config files is just a waste.
I really don't get it; the whole point of computing is to make stuff rigorous and precise so that you don't have to run a whole guesstimate translation layer as you need to with humans.
Can someone explain to me what is so horrible about curly braces that we need a whole host of "human-friendly" configuration languages with nontrivial parsing just to get around them?
I can see someone wanting the Markdown of markup languages: more convenient for people to read and write. Sure, without markdown you could write HTML, say. But editing Markdown is a nicer experience.
JSON 5 is pretty good. It just needs to make the top-level brace and all commas optional, and add proper support for multi-line strings (writing '/n/' at the end of every line doesn't count).
Allowing only valid JavaScript identifiers to be unescaped keys is also a bit quirky (You have to quote reserved keywords).
But they will never change any of that because it would break JavaScript compatibility.
Oh lord. We already have TOML, which is an improvement on limited JSON when a human-readable, easily-diffable, more flexible format is needed.
We don't even need HCL (offers little value), YAML (has too many features making it inherently less secure), XML (is a mess with too many features and too much verbosity), or INI (insufficient features) except for existing and historical reasons.
In cases where a single file is attempted to be managed by multiple, competing interests, it's probably better to split the file into multiple, modular/include files like *.d/* so there would be less chances for merge conflicts.
And then there's /{proc,sys}-like configuration with one "value" per file where the path forms the heirarchy.
Please. Just. Stop reinventing wheels that were already round enough.
Reminder: you can use indentation to encode s-expressions. The result is very easy to parse and easy to read provided the underlying data structures are not insane.
If the goal is to look similar to YAML and fix its problems and assert itself as something that's needed in a world with YAML, the introduction should probably explicitly call out some clear differences.
`::` is quite strange. 1) It only allows to resolve nesting conflicts for a single level. 2) Could be hard to read and could lead to reasoning mistakes. 3) Looks like an attempt to differentiate HUML from YAML somehow.
LSP is the only thing that matters to me, regardless of the language I’m evaluating.
Weeks of my life have been reclaimed thanks to TypeScripts LSP.
All configuration languages suck in Monaco, so much so that I would rather use C# or TS to generate a config with docs in the tooltips, red squiggles under my typos, and location-aware autocomplete.
31 comments
[ 4.9 ms ] story [ 71.9 ms ] threadTerm not found.
TRUTH!
Or, expressed in YAML 1.1 [1]
As expressed in YAML 1.2 [2]:I shouldn't have to care about what the type of the value is when writing out effectively YAML. This double-colon feature will do nothing but lead to bug reports from people confused as to why their document is invalid.
Tokens are inseparable from human instincts of single = less, double = more and the corresponding emotions: single=less=easier=quicker, double=more=complicated=longer=difficult
If you are not emphasizing the single token as them most common, it's going to cause confusion.
Or restrictions like "only one space allowed after : before a value"
25 minute talk at https://www.youtube.com/live/AUrPdOZNsX8?feature=shared&t=13... (starts 3h:52)
The talk proposal is at https://fossunited.org/c/indiafoss/2025/cfp/arsnhack6n
And it primarily tries to avoid YAML horrors : https://noyaml.com/ and https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr....
[0]: https://fossunited.org/indiafoss/2025
The ones who read the XML file understood immediately. Why ? Because XML is self-documenting and the repetition via clear de-limitation extensively aids human memory.
The one who read the JSON file just glazed over it and needed to refer back to the document and re-read several times.
I urge all the XML naysayers and XML haters to please carry out this practical test with their colleagues. Please choose a good level of complexity and nesting and please make use of XML attributes for scalar values.
XML is SO FAR ahead in readability and grokking that it is not funny.
I really don't get it; the whole point of computing is to make stuff rigorous and precise so that you don't have to run a whole guesstimate translation layer as you need to with humans.
Can someone explain to me what is so horrible about curly braces that we need a whole host of "human-friendly" configuration languages with nontrivial parsing just to get around them?
Allowing only valid JavaScript identifiers to be unescaped keys is also a bit quirky (You have to quote reserved keywords).
But they will never change any of that because it would break JavaScript compatibility.
We don't even need HCL (offers little value), YAML (has too many features making it inherently less secure), XML (is a mess with too many features and too much verbosity), or INI (insufficient features) except for existing and historical reasons.
In cases where a single file is attempted to be managed by multiple, competing interests, it's probably better to split the file into multiple, modular/include files like *.d/* so there would be less chances for merge conflicts.
And then there's /{proc,sys}-like configuration with one "value" per file where the path forms the heirarchy.
Please. Just. Stop reinventing wheels that were already round enough.
https://srfi.schemers.org/srfi-49/srfi-49.html
Not sure which one we have here.
Weeks of my life have been reclaimed thanks to TypeScripts LSP.
All configuration languages suck in Monaco, so much so that I would rather use C# or TS to generate a config with docs in the tooltips, red squiggles under my typos, and location-aware autocomplete.