YAML: probably not so great after all (2017)
61–70 of 412 posts
Re: YAML: probably not so great after all (2017)
#62Earlier quoted context omitted.
My biggest complaint with JSON is the lack of support for comments. For that reason, it's hard to take it seriously for human-maintained configurations.
Comments and trailing commas. If those two features were added, I would use JSON for configuring everything. Naked keys would be a distant third. My conclusion is to use TOML or the protocol buffer text format. I've been slowly ripping out YAML support and converting configurations to TOML.
Not just trailing commas, but the need for commas at all when there is a newline right next to it has been a source of many stupid issues for me when less knowledgeable/experienced people edit json based conf files.
Then there is floats without a leading zero. Missing colon after the key. And yea, naked keys. The need to wrap the entire file in { } or [ ] is just icing.
Honestly I feel the most bare simple conf format of [first-word] [rest-of-line] is enough for many programs that end up using but never taking advantage of more powerful formats.
Re: YAML: probably not so great after all (2017)
#63One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary effort). Even articulating the problems with XML's approach was an uphill battle. What you would replace it with is also hard. What use cases matter? What is the core model? A simple hierarchy? Typed nodes? A graph? What sort of syntax is needed for it to be usa…
Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below).
* I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".
Re: YAML: probably not so great after all (2017)
#64I write a lot of command line tools for work and need configuration files and always go for YAML, but am never happy about it. I use it because it serializes to Ruby objects so I can more easily do validation and check if someone forgot an important key but I wish there were something that would make that easier for the people using the config files. I looked into TOML after this and liked what I saw.
Re: YAML: probably not so great after all (2017)
#65Object graphs are the answer to the endless iteration on the right config format: http://codesolvent.com/config-node/ it is however difficult to pull off and requires productization, in other words not low-level tooling in a text file.
That link is pretty terse. I have no idea what "object graphs" are in this context nor how they solve the "endless iteration on the right config format" problem. Moreover, churn on config file formats is probably the least of my dev problems.
"object graphs" means exactly what it typically means...ie objects composed of other objects.
The key is that you have to have a way to create such graphs beyond code (ie new Resource({"attr":value}..)).
Text file formats are always going to be an issue the moment your requirements are complex.
Here's another example of what I am referring to:
Re: YAML: probably not so great after all (2017)
#66With YAML I can never remember what's an object versus a list, string, or number, nor am I ever able to add new stuff to a YAML file and get it to parse correctly without first looking up the spec. And it's impossible to see where large objects start and end. In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trail…
In contrast, JSON is super intuitive and basically self documenting. Personally I've found the exact opposite when dealing with 'normal' people. Most people can get basic YAML, but unless they're a programmers (or at least know how to program) most people fail miserably at writing JSON by hand.
I agree with this. Our biz guys have to edit JSON config files regularly, and they're limited to basically just copying/pasting lines from existing files and editing the values. When they need to be able to do more, we end up building a UI for it and either storing the config elsewhere or writing the code to manage persisting their changes to the config.
Re: YAML: probably not so great after all (2017)
#67One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary effort). Even articulating the problems with XML's approach was an uphill battle. What you would replace it with is also hard. What use cases matter? What is the core model? A simple hierarchy? Typed nodes? A graph? What sort of syntax is needed for it to be usa…
It's not really a moral judgement, thanks for your contributions and your innovations, but I prefer not to use YAML if possible for the same reasons the author outlined.
Re: YAML: probably not so great after all (2017)
#68Earlier quoted context omitted.
> In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trailing comma. I'd expand the list of quirks... JSON lacks comments (both line-level and block level). Fine for data transport but super super bad for configuration files.
>Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. -Douglas Crockford, creator of JSON There is no issue using JSON with comments for a config file.
Yes, except for the fact that ECMAScript has a syntax for comments, but not JSON. Standards matter.
Re: YAML: probably not so great after all (2017)
#69A thread hating on YAML without a mention of the bastardized YAML that ansible uses?
Ansible extends yaml so that:
cmd: a b c
is actually but not quite identical to:
cmd: ["a", "b", "c"]
It also embeds JINJA2 templating part-way (!) through the YAML parsing process.
The gotchas that these and other bastardizations cause is only partially documented at the bottom of this page: https://docs.ansible.com/ansible/latest/reference_appendices...
I like ansible, but its decision to use a bastardized YAML is a major pet peeve of mine.
Re: YAML: probably not so great after all (2017)
#70We've spent like 10 years trying to fill in gaps left when we all decided to hate XML. JSON is great as a lightweight DIF between trusted partners. If you care about maintenance and safety, XML with XSD is rock solid.
Safety? The OWASP Top 10 doesn't feature a JSON security issue.
https://www.owasp.org/index.php/Top_10-2017_A4-XML_External_...