Slightly off-topic: Why is JSON so popular for this sort of thing? I think it's fine for programs communicating with each other, but I really don't understand why anyone would want to have to match brackets when writing a configuration file
- There are lots of great libraries for nearly every language to parse it, or they're built in
- It's got the benefits of XML (tags are right next to the data, unlike CSV) while being way less typing
- It's easy to scan since I'm already used to seeing [] and {} to represent common data structures
- I can pretty print it or remove whitespace
- It's popular, meaning there are lots of tools to work with it, but it's simple enough that a text editor will do
- Most text editors will match brackets and indentation for me, so it's not a huge issue
I have some (private) libraries in C++, Python, and Nim that support those features, too. Basically it understands JavaScript object literals. If I find some time, I'll package them up and publish them.
One thing I'd really like to change is to make the parser round-trippable, so it remembers all the whitespace and comments, and if you use these pseudo-json as config files, you can make programmatic changes without loosing anything.
Personally I do miss them tremendously though.
YAML feels to me like the creation of a person who has never fought with a makefile that imported another makefile that had an extra tab on line 9432: not quite true hell, but a few hours of trying to figure out WHY things aren't working right you would be hard pressed to tell the difference.
YAML says there's a world of difference between
- flag1
- option2
-flag1
-option2
[
"flag1",
"config2"
]
"-flag1 -config2"
Personally, live python as config is my preference, followed by YAML because comments, but YAML isn't perfect.
If the options are right next to each other it's clear there's a misalignment:
- option1
-option2
- option1# multi-line comment
# as is sometimes seen in config
# files, sometimes it can be hard
# to see the misalignment.
- option2YAML quickly gets cranky and brittle, there are too many ways to do everything, and it's very challenging to easily debug some of the syntax errors. If I had to do it over again, I'd probably go with json over yaml.
With JSON, I can have my text editor do the validation before I even save. That kind of tooling just doesn't exist for YAML.
When I first encountered an ESLint config written in YAML, for example, it took me like a dozen tries (no exaggeration) to successfully convert a
[2, "always"]
[2, { "options": blah, "foo": bar }]
I came to dislike it even more once I found out it had features like &anchors, <<:, etc. Not only do I find the syntax repulsive, but having custom user-named sections whose identifiers aren't actually significant and don't end up in the parsed structure is probably wasting a ton of people's time as they Google documentation for config section names that the consuming program doesn't actually understand because they don't really exist (they were just named at the author's whimsy).
It's not worth it. Use JSON, or possibly JSON5.
Since yaml is a superset of json, any valid json is valid yaml as well. This allows you to combine the two in very convenient ways:
---
test:
obj: {"solution": ["in", "the", "list", {"everything: "is possible"}]}This is wrong.
I rather just start with a real Python or JavaScript object literal in my source, and when it grows, move it to a new file, and run over it with a lenient JSON parser.
for example I just googled "lightweight online json editor mobile no registration" and was very pleased.
the more popular json gets, the objectively better choice it becomes.
you can edit it in a browser, as I just showed you, then copy the result over. it's great!