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…
YAML: probably not so great after all (2017)
31–40 of 412 posts
Re: YAML: probably not so great after all (2017)
#32We'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.
I don't know, XML is awfully verbose and the schemas are even more verbose. I've lost track of how many "XML" configuration files that looked like this:
ApplicationName
WhizBang
...
Re: YAML: probably not so great after all (2017)
#33With 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…
You use JavaScript a lot more than python, right? Intuitive usually means "close to what I'm used to".
I actually use Python a lot more than Javascript. That's why the double quotes and the no trailing comma are always what get me.
Especially since leaving the trailing comma is considered the best practice in every other language.
Re: YAML: probably not so great after all (2017)
#34One 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 usable? These were all questions. Seen in context, we got quite a bit correct. And yes... it has a few embarrassing warts and a few deep problems. Ah well.
A second thing to consider... YAML was created before it was common that tech companies actively contributed to open source development. There are lots of things we could have done differently if we had more than a few hours per week... even a tiny bit of financial support would have helped.
Finally, YAML isn't just a spec, it has multiple implementations. Getting consensus among the excellent contributors is a team effort, and particularly challenging when no one is getting paid for the work. Once you have a few implementations and dependent applications, you're kinda stuck in time.
It was an special pleasure for me to have had the opportunity to work with such amazing collaborators.
We did it gratis. We are so glad that so many have found it useful.
Re: YAML: probably not so great after all (2017)
#35Those reasons are exactly why I created mset. It's not as flexible as Yaml but it is dead simple and works for many use cases. It is also very easy to implement in any language and more importantly super simple to learn for end users.
Re: YAML: probably not so great after all (2017)
#36With 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.
Re: YAML: probably not so great after all (2017)
#37With 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…
You use JavaScript a lot more than python, right? Intuitive usually means "close to what I'm used to".
Python dicts are a lot closer to JSON than YAML.
The real schism here, IMO, is Programmer Intuitive vs. Natural Language Intuitive.
Re: YAML: probably not so great after all (2017)
#38> Can be hard to edit, especially for large files
How does this entire section not also apply to JSON?
Re: YAML: probably not so great after all (2017)
#39I am sad that EDN hasn’t achieved popularity as a format. It seems like a better specified, less verbose format. As a bonus it plays well with Paredit-like editor modes. Alas, the curse of being better, but later.
Re: YAML: probably not so great after all (2017)
#40I 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 nine yards.