Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

91–100 of 412 posts

Re: YAML: probably not so great after all (2017)

#91
post #40
post #5

I agree with some of the author's points but the "surprising behaviour" section is odd. For example, why would you expect `3.5.3` to be parsed as a number? How could that be parsed as a number?

The 013 to 11 issue is pretty obvious to any seasoned programmer. For example C, Ruby, and yes, also Javascript have the same "problem". Octal 13 is decimal 11. JSON should actually have the same issue. When I enter { 013: "11" } in the web console I get '{11: "11"}'. And YAML is backwards compatible to JSON. That's IMO the actual problem of YAML. It could have supported a reasonable subset of JSON and not the whole…

> JSON should actually have the same issue. When I enter { 013: "11" } in the web console I get '{11: "11"}'.

JSON doesn't have this issue. `{ 013: "11" }` isn't valid according to the JSON spec for a couple reasons, the important one being that multi-digit numbers cannot start with zero[1]. Try this in the console: `JSON.parse('{"11": 013}')`.

[1]: https://tools.ietf.org/html/rfc8259#section-6

Re: YAML: probably not so great after all (2017)

#92

Earlier quoted context omitted.

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 forma…

> but the need for commas at all when there is a newline right next to it

JSON is often minified though - you're going to need something to use as a delimiter

Re: YAML: probably not so great after all (2017)

#93
post #74

Earlier 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.

JSON5 supports comments, and is only slightly more complex than JSON. https://json5.org/

Most parsers will not support JSON5.

Re: YAML: probably not so great after all (2017)

#94
For config formats I'm finding HCL[1] to be nice for my use cases. It has comments, no requirement for double quoted identifiers, and is actually simple. The main issue was the only implementation is in Go, so I had to write a port to C++.

[1] https://github.com/hashicorp/hcl

Re: YAML: probably not so great after all (2017)

#95
post #2

We'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.

Well, if you go deeper down the rabbit hole, XML was a complete and utter waste of time. This problem was solved in the 60's with S-Expressions.

Re: YAML: probably not so great after all (2017)

#96
post #74

Earlier 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.

JSON5 supports comments, and is only slightly more complex than JSON. https://json5.org/

The barrier here would be whether there's support in enough implementations to feel safe using it in the wild, which I'm guessing will take a while at the very least.

Re: YAML: probably not so great after all (2017)

#97

One 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…

JSON definitely did exist 20 years ago.

> Douglas Crockford originally specified the JSON format in the early 2000s

Re: YAML: probably not so great after all (2017)

#99
post #6

With 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. 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.

JSON lacks comments (both line-level and block level)

    “_comment”: “blah blah blah”,
Simples

Re: YAML: probably not so great after all (2017)

#100
post #6

With 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. 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.

> lacks comments [..] super super bad for configuration files

Not that that matters when applications take it upon themselves to re-save the config file in some kind of normalisation effort. Bye-bye comments, hope they're checked in somewhere.

I'm lookin' at you, kubernetes...

Post reply on HN