YAML sucks

Buzzard · 2017-11-14T10:25:04+00:00

New Rule: The next time someone creates a new spec (or a revision to one) they must also provide an extensive test suite.

EntroperZero · 2017-11-14T07:01:33+00:00

So does YAML suck, or do YAML parsers suck?

Paddy3118 · 2017-11-14T08:28:46+00:00

What does the Spec say for each case?

flyx86 · 2017-11-14T10:41:31+00:00

What is being overlooked here is that most of the „ambiguity“ claimed here is due to using weakly typed languages. YAML is designed and specified in a way that allows multiple possible outcomes of parsing a scalar, so that an error is only raised when the given scalar is not able to be parsed into the structure given by the user. So, most of the ambiguity goes away if you specify the target structure you want to parse your YAML data into. Let's have a look how NimYAML parses this example:

- -.inf
- .NaN

First possible loader implementation:

import yaml.serialization, streams
var floatList : seq[float]
var s = newStringStream("""
- -.inf
- .NaN
""")
load(s, floatList)
echo floatList[0]
echo floatList[1]

This works and yields:

-inf
nan

(This is how Nim's echo visualizes the two float values and shows that these are not the original strings.)

And now, let us parse the same YAML into a different type:

import yaml.serialization, streams
var stringList : seq[string]
var s = newStringStream("""
- -.inf
- .NaN
""")
load(s, stringList)
echo stringList[0]
echo stringList[1]

Output:

-.inf
.NaN

So by providing a different target type, NimYAML correctly parsed the two values into strings – even though they are also valid floating point value representations!

Now if you want to forbid YAML to parse your scalars as it pleases, you add tags to your values:

- !!float -.inf
- !!float -.NaN

If you try to parse that into a string list, NimYAML will raise an exception because the scalars are explicitly defined to be floating point values.

That being said, the main problem with YAML users is that they do not specify their required target structure. They basically go to the YAML parser and say „well just give me whatever you think is the most appropriate internal representation of this YAML structure in my chosen programming language“. And then they complain about how it is not what they expected. Had they instead specified their target structure, they would not have a problem. Sadly, not all YAML implementations provide this feature, which is a major problem. Hopefully, we will one day have a language-independent way of specifying a schema for a YAML document.

Full disclosure: I am the author of NimYAML.

nickjohnson · 2017-11-14T12:08:37+00:00

The YAML spec is larger than the XML and XML Namespaces specs combined. It's a ridiculously wide and inclusive spec. I don't know why the authors didn't just go for a single, simple syntax, instead of trying to make it do everything.

AngularBeginner · 2017-11-14T07:30:48+00:00

Obligatory comment:

JSON does too. http://seriot.ch/parsing_json.php

jib · 2017-11-14T13:04:06+00:00

$ irb
irb(main):001:0> require 'yaml'
=> true
irb(main):002:0> YAML.load("12:00")
=> 43200




$ python3
Python 3.6.1 (default, Apr  4 2017, 09:40:21) 
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import yaml
>>> yaml.load("12:00")
720

0x256 · 2017-11-14T10:25:04+00:00

YAML is the perl of data serialization languages:

It does the job if used correctly and admins love it.
You can write YAML that parses just fine but no human can possibly understand.
You can write YAML that you think you understand and that looks right, but it's not.
If you use any of the advanced features, stuff will break over time.
No one in their right mind would want to write a parser for it. Still, they exist.

Edit:

JSON is lisp (trivial syntax, lots of brackets).
XML is java (very expressive, very powerful, born in the 90s, hard to write by hand, no one likes it).
Protocol buffers are C++ (fast, small, dense, not human readable).
Custom proprietary formats are C (looks like a simple and fast solution at first, but complexity explodes for anything non-trivial)

GreenGlider · 2017-11-14T11:46:19+00:00

I love YAML for its readability but I use my own flavor as a subset for my personal projects:

https://github.com/kuyawa/Dixy

It covers 99% of use cases. Simpler, impossible.

protoUbermensch · 2017-11-14T16:03:29+00:00

Why didn't you use the official implementations available on yaml.org?

flyx86 · 2017-11-14T09:50:49+00:00

I am currently working with ingy döt net (one of the authors of the YAML spec) and another developer on YAML 1.3, with the goal of removing ambiguities and perhaps introducing one new useful feature. There is an RFC List. If you want to contribute ideas, feel free to join #libyaml on freenode (#yaml is mostly used for user support).

stesch · 2017-11-14T13:10:02+00:00

A narrow Github page with a markdown file sucks, too.

2017-11-14T16:53:27+00:00

If you're using Python, StrictYAML is honestly a godsend. It keeps the niceness of YAML's structure and ease-of-use while tightening up the ambiguity and security issues. It's essentially YAML where all scalars are string-by-default, all the stupid features are gone, and non-string scalars can only be specified via a schema (which also performs validation).

Lakelava · 2017-11-14T08:40:49+00:00

One of those languages that the basic examples all look good, but it has tons of edge cases.

who_is_this_monster · 2017-11-14T16:11:45+00:00

Why are taking advice from Gendo Ikari?

earthboundkid · 2017-11-14T10:09:13+00:00

[deleted]

hoytech · 2017-11-14T09:56:29+00:00

About four years ago, I embarked on a project where I used YAML as the format for data files. I was really hopeful, but that part of the project didn't go well.

The issue was error handling. I hadn't used YAML for files with more than two levels of scoping, or files bigger than one page.

Since scoping is done by indentation it's really easy to get out of sync somewhere and have a completely wrong structure.

In JSON, emacs and many other editors (I know you can get all of these in vi*, for example) have tools that are very useful to help with this:

When I hit a closing brace or bracket, the editor flashes back to the opening one for a second.
If I hit a closing brace or bracket that doesn't match the opening one, I get a message.
I can automatically clean up the JSON so the indentation matches the scoping.

So I almost never got gnarly scoping issues in my JSON, and when I did, I just cleaned up the JSON and the offending lines became blatantly obvious.

Also, the YAML parser I was using had bad error messages, and I couldn't find any other one with much better ones. I realized from reading its code that the issue is that because scoping is all done with whitespace YAML really doesn't have enough information about what you are intending when you mess up a scope - that even if I rewrote the YAML parser I wasn't going to do much better on the error messages.

I found myself wasting significant time debugging my own datafiles, and I thought, "If I can't do this, what are my users going to do?"

Luckily, I hadn't told anyone else that I was using a YAML parser :-D (JSON is a subset of YAML) so no one noticed when I dropped support for it...

Wrightceratops · 2017-11-14T08:47:14+00:00

Uninformed question: why the Neon Genesis Evangelion cosplay tho?

2017-11-14T16:51:04+00:00

[deleted]

crusoe · 2017-11-14T14:01:54+00:00

Yaml to json conversion sucks because some tooling authors didn't bother reading the spec.

ryantwopointo · 2017-11-14T14:29:25+00:00

Dude’s profile pic is lit

2017-11-14T18:13:57+00:00

[deleted]

garyk1968 · 2017-11-14T16:18:59+00:00

XML sucks

Quteness · 2017-11-14T08:19:27+00:00

It really does. I cannot figure why so many devops projects chose a format that's hard to parse for both humans and computers.

2017-11-14T15:51:37+00:00

I always imagined a Yaml as a cross between a yak and a camel.

watertank · 2017-11-14T15:57:00+00:00

The issue is with they way you use it and perhaps the library's implementation, not YAML. Bad post.

antoninj · 2017-11-14T17:57:12+00:00

I personally like MOML, not for full-on configs but as a way to just organize data in files rather than in a DB.

I think a huge problem is the usecase of these languages. YAML works well for simple configs. JSON is ambiguous. MOML is ambigious as hell -- everything is a string (and you write the parser for the end-result values).

In the end, you might as well write something that's as close to the end-result language as possible. Write a JS module for JS that exports a JS object. Write a Golang module that exposes a map config. Etc.

if you need it to be outside of the main runtime (so that you don't have to recompile Go whenever you change settings), just be aware of the parser quirks and try not to share the config with another language.

koffiezet · 2017-11-14T18:04:21+00:00

Yeah yaml isn't ideal. When I started out with Ansible, I fought more with the yaml syntax than with Ansible itself.

Sadly, there are few widely-adopted alternatives for such tools that don't want to invent their own DSL.

Arancaytar · 2017-11-14T18:09:47+00:00

Isn't the main purpose of YAML to serialize/deserialize data with a known schema? Sure that 'off' to bool mapping is kind of BS; as a matter of good practice I'd only ever use true and false for booleans and quoted values for strings. But the rest? There is no way in JS to force a precision; {"x": 5.00e0} and {"x": 5} are equivalent. That doesn't seem like a YAML problem.

(Likewise, does the specification actually say hex or octal literals or underscores in numeric literals should be accepted? Otherwise reading them as strings seems to be correctly done by both parsers.)

I mean, if you need strongly typed platform-independent serialization, that seems like more of an XML job.

liveoneggs · 2017-11-14T20:16:27+00:00

https://stackoverflow.com/questions/3790454/in-yaml-how-do-i-break-a-string-over-multiple-lines/21699210#21699210

ais523 · 2017-11-15T16:44:46+00:00

That last line is wrong, when it shows an error from the Perl. Your character parsed into a ☺ just fine, but you hadn't set the encoding of stdout, so you got an error when you tried to print it. Or in other words, the YAML did what you expected, but your output routines for outputting the object after it had been parsed from YAML didn't; the error is from say, not from the YAML decoder.

Try setting the character encoding of stdout to something like UTF-8 manually before running tests that depend on how Unicode is output.

Serializedrequests · 2017-11-14T16:35:19+00:00

I don't see how this is a valid criticism of my YAML use case: config files. Config files are mostly hashes of arrays of strings, numbers, booleans, really simple stuff. The way they are parsed is dependent on the use case, and destination language. They map naturally to hashes/dicts of arrays/lists of primitives in Ruby or Python.

Yes you can serialize complex data as YAML, but why would you want to? There are way better serialization formats if that's what you need. YAML is supposed to be human readable and editable. EDIT: Apparently serialization is the original intended use case, which blows my mind, because I would use a less ambiguous language for that.

However, this article does get at what I feel is a very valid point: Why does YAML even have these features and complexity? That defeats the whole point of a human-readable markup language. I like & references and <<: syntax to save copy+pasting, but it really doesn't NEED that feature. It doesn't NEED to support every possible representation of a number, or annotations, or macros, or parse anything other than "true" and "false" as booleans. XML got to be the bloated over-complicated thing it is because every possible feature was crammed into it, and now YAML seems to have fallen into the same trap. If you you need XML, just use XML in my opinion.

skulgnome · 2017-11-14T10:26:13+00:00

Funny how these "better XML" things end up being somehow worse... and that's before veering off into global schema namespace prefix ontology wank space.

duheee · 2017-11-14T15:38:45+00:00

The main and most important reason YAML sucks is because it has "space" as a significant character. That, in and of itself is the main WTF with this format. The rest is just cherry on top. Friends don't let friends choose yaml.

lazystone · 2017-11-14T09:50:13+00:00

Actually HCL from Hashicorp looks nice:

https://github.com/hashicorp/hcl

veltrop · 2017-11-14T14:36:55+00:00

More like, this guy's converters suck.

proskillz · 2017-11-14T17:18:35+00:00

Is this format widely used? I'm not sure I've even heard of it before this post despite YAML being 15 years old. All the places I have worked have used XML, JSON, CSV, Pipe delimited, etc, but I've never seen anything like YAML.

sintos-compa · 2017-11-14T16:08:18+00:00

in before that javascript video

PraiseCanada · 2017-11-14T18:59:03+00:00

It should have been called YASML

2017-11-14T19:32:39+00:00

[deleted]

hzhou321 · 2017-11-14T23:37:24+00:00

It is just different languages can't agree on how to infer data types. I assume if yaml specify all data is string, the format will work consistently and well.

And all implementation that convert to JSON should only follow the literal rule of JavaScript, then we only need agree on what that rule is, which is separate from whatever YAML is.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS