I never understood how YAML is more human-readable than JSON. I find JSON much easier to read.
What annoys me the most about YAML is that it's easy to misinterpret the indentation.
You need a special IDE to know whether a property belongs to a specific object or to its parent.
YAML: Probably not so great after all
121–130 of 457 posts
Re: YAML: Probably not so great after all
#122So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?
.ini, followed by TOML, followed by an identical implementation of some other app's config format.
The biggest problem with config formats is they mislead users into thinking they understand the format. The user tries to edit it by hand, and chaos ensues. So only formats that are stupidly simple, or whose warts are already familiar and well documented, are good choices.
Apache had a great configuration format. Nothing else used it (that I knew of) but you could in theory implement "Apache configs" and then people'd just have to look up how to write those, which there's lots of examples of.
JSON and YAML and XML are data formats; they should only be written by machines, and read by humans. Same with protocols like HTTP, Telnet, FTP... You're not supposed to write it yourself, but it's readable to make troubleshooting easier.
Data formats are nice for expressing nested data structures, but then they don't (usually) support logical expressions; at that point you need a template/macro/programming language, and at that point you're writing code, which will need to be tested, and at that point you should just write modules and use a config format to give them arguments. Every complex tool goes through the same evolution.
If you care about your users, write a tool to generate configs based on a wizard. Good CLI tools do this, and it really makes life better. (It's also a great way to document all your config features in code, and test them)
Re: YAML: Probably not so great after all
#123Earlier quoted context omitted.
Would you say actual YAML does a better job in Ansible over just writing JSON and letting it be parsed as YAML?
I can at least write comments in YAML.
That's probably the biggest thing YAML has going for it and probably the only feature I take advantage of when something takes YAML instead of JSON.
Re: YAML: Probably not so great after all
#124So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?
It's telling that the responses to this question are broad and varied. Still not a well solved problem, it seems.
Re: YAML: Probably not so great after all
#125The first example (i.e. `yaml.load()` in Python) doesn't work with the current version of PyYAML.
Function application was disabled some time ago, and `yaml.load()` logs a noisy deprecation warning telling users to use `yaml.safe_load()` instead [1].
[1]: https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-...
Re: YAML: Probably not so great after all
#126As an ansible user, I hate YAML and its broken parsers with a passion, but the security objection does not make much sense. It does apply verbatim to any parser of anything if the implementation decides that a given label means "eval this content right away". I fail to see how this can be a fault of the DDL rather than the parser's.
The reason this is a fault of the DDL and not the parser is that the DDL spec decides that it has label that evaluates a command. The parser then has two options, either implement it or not conform to the spec (and essentially implementing a different DDL). For programming languages it makes sense to have an eval label/command. For configuration/serialization DDLs I think it's a terrible choice.
Re: YAML: Probably not so great after all
#127I just want json with comments. Is that too much to ask?
Re: YAML: Probably not so great after all
#128fish shell is looking for a new text serialization format for its history file (currently it uses an ad-hoc broken psuedo-YAML). Boxes to check: 1. Self describing format 2. SAX-style parser available to C++ 3. Easy for users to understand and ad-hoc parse using command-line tools 4. No document closing necessary, so appending is trivial YAML looks pretty good: - cmd: git checkout file.txt when: 1565133286 pwd: /home…
I'm tempted to suggest CSV.
Re: YAML: Probably not so great after all
#129So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?
J S O N all the way.
Re: YAML: Probably not so great after all
#1301. General purpose serialization format is released.
2. Format is declared to have x and y problem, new format is invented that is "simpler and better"
Time passes
3. People slowly discover format in #2 has the same issues that led to creating #1.
Repeat.
(Just like attempting to super-generalize anything else)