Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YAML document from hell (2023)

ruudvanasseldonk.com

Post reply on HN
Print view View original

121–130 of 144 posts

Re: YAML document from hell (2023)

#121

Post by nucleardog »

aranw wrote: post #22

I find it remarkable that YAML has become our goto for configuration when it is riddled with parsing traps and inconsistent behaviour that catches out even experienced developers

It's the least-annoying option in a lot of cases.

JSON is for computers. Writing and editing by hand is not great. Escaping things sucks. A simple multi line string or something gets really awkward.

XML goes too far the other way... it's annoyingly verbose to write by hand. Escaping can get annoying. It often allows you to represent data structures that are not easily representable in various languages.

INI sucks because it lacks a specification. It also sucks for nested data.

TOML fixes this by essentially specifying a better INI file. Much like an INI file, this falls apart at any real level of nesting.

EverythingElse is not widely supported.

When it comes to basic configs and stuff humans need to work with, I usually start with a basic K=V format. Writing a "parser" in any language usually takes about one minute and has no dependencies so is an easy win.

As soon as a use case grows beyond that (quoting, explicit typing, multiple lines, escapes, whatever) I just move to YAML. It's not the best, but it's easily available and the least bad from my point of view.

Re: YAML document from hell (2023)

#122

Post by kibwen »

pavon wrote: post #116
com2kid wrote: post #93

Earlier quoted context omitted.

Genuinely curious - What major flaws does TOML have? I've used it before and it seems like a simple no-nonsense config language. Plenty of blog articles about the flaws behind YAML, I don't really see complaints about TOML!

INI-like formats are perfectly fine for config files with at most one layer of nesting/sections. TOML is a perfectly fine INI-like parser. Its definitions and support for strings, numbers, comments, sections and simple arrays are great. But its main claim to fame is extending INI to support arbitrary levels nesting of arrays and dictionaries like JSON, and IMO it does a horrible job at it. With JSON, YAML, XML and ma…

> And the more nested the format becomes, with arrays of dicts, or dicts of arrays, the harder it is to follow.

While I have some minor annoyances with TOML, I counterintuitively consider it a strength of the format that nesting quickly becomes untenable, because it produces pressure on the designers of config file schemas to keep nesting to a minimum.

Maybe some projects have a legitimate need for something more complex, but IMO config files are at their best when they're just key-value pairs organized into sections.

Re: YAML document from hell (2023)

#123

Post by maxbond »

tgv wrote: post #78
maxbond wrote: post #28

Earlier quoted context omitted.

Halloween isn't for a few more weeks, but this framework for creating bespoke YAML dialects that can only be parsed by a specific implementation and with the correct type annotations will scare the pants off of your devops colleagues around the campfire. (In case I haven't succeeded in hitting the right tone, this is intended to be good-natured jest and not snark.)

Well, JSON cannot represent dates (nor Sets, Maps, NaN, etc.), so quite a few applications with a JSON parser have their own conversion (e.g. seconds since epoch, string parsing, object with date fields). Is that a bespoke JSON dialect that scares the pants off? Now, JSON is more suited for machine-to-machine, but YAML works fairly well for humans. It's a pity, but a few domain specific don't really hurt, since you c…

I'd say that isn't a JSON dialect because that's postprocessing applied after parsing, versus hooking into a YAML parser to change the semantics of how `no` is parsed. But it is a good point.

I did run into a project once with a very cool custom YAML parser to recommend how to recover from errors. I think you do have to type check all deserialization, and you should fail if you process a bool where you expect a string. Automatically fixing things can be very dangerous. But if you were going to do it, the way you described is the best way to do it.

> Well, JSON cannot represent ... NaN ...

Here's another horror story:

    >>> # Python 
    >>> json.dumps({"foo": float("nan")})
    '{"foo": NaN}'

    > // JavaScript
    > JSON.parse('{"foo": NaN}')
    Uncaught SyntaxError: Unexpected token 'N', "{"foo": NaN}" is not valid JSON

Re: YAML document from hell (2023)

#124

Post by Dylan16807 »

lucideer wrote: post #53
twelvechairs wrote: post #5

Almost all of this is solved by basically putting quotes around strings. Yaml has its uses cases where you want things json doesnt do like recursion or anchors/aliases/tags. Or at least it has had - perhaps cue/dhall/hcl solves things better. Jsonnet is another. I havent tried enough to test how much better they are.

I feel like these two tenets - (1) yaml should require quotes & (2) the value in yaml is in recursion/anchors - are fundamentally the opposite of why yaml exists & why people use it. The distinguishing draw of yaml is largely the "easiness" of not having explicit opening or - more importantly - closing delimeters. This is done using a combination of white-space delimiting for structure, & heuristic parsing for values…

Is - not effectively an opening delimiter?

If we want to avoid quoting in particular, then we could use - for strings and anything else for non-strings. But the heuristics suck.

Re: YAML document from hell (2023)

#125

Post by Dylan16807 »

lillesvin wrote: post #91
montroser wrote: post #60

Earlier quoted context omitted.

As the article points out with the `on` example, you really have to quote yaml keys as well, if you want the defense to work...

The argument was that most of the mentioned problems could be solved by quoting the values. I don't have a problem with avoiding "on" as a key, and I apparently haven't used it ever, because I've never run into this particular problem in my 15+ years using YAML. So, sure, if you want to play it super safe, quote keys as well. But I'm personally fine with the trade-off in not quoting keys.

If you compare to JSON5 instead of JSON, you still get the benefit of unquoted keys, but you also get a guarantee the keys are strings, and it's harder to forget to quote a value.

Re: YAML document from hell (2023)

#126

Post by xg15 »

> While keys in json are always strings, in yaml they can be any value, including booleans.

TIL that yaml and json do not have the same data model and there are yaml documents that are not representable as json...

Re: YAML document from hell (2023)

#127

Post by array_key_first »

nucleardog wrote: post #121
aranw wrote: post #22

I find it remarkable that YAML has become our goto for configuration when it is riddled with parsing traps and inconsistent behaviour that catches out even experienced developers

It's the least-annoying option in a lot of cases. JSON is for computers. Writing and editing by hand is not great. Escaping things sucks. A simple multi line string or something gets really awkward. XML goes too far the other way... it's annoyingly verbose to write by hand. Escaping can get annoying. It often allows you to represent data structures that are not easily representable in various languages. INI sucks bec…

Unironically PHP arrays are the perfect config format. Nestable like JSON, terser, no parsing traps, typed.

I mean, this is just great:

```php

[

  'driver' => 'mysql'

  'options' => [...],
];

```

Obviously not a lot of support though... Its PHP.

Re: YAML document from hell (2023)

#128

Post by xg15 »

> There exist various extensions of json that extend it just enough to make it a usable config format without introducing too much complexity. Json with comments is probably the most widespread, as it is used as the config format for Visual Studio Code. The main downside of these is that they haven’t really caught on (yet!), so they aren’t as widely supported as json or yaml.

What blew my mind was learning that the entire JSON grammar is included as a subset in the YAML grammar. So every valid JSON document is automatically a valid YAML document.

But you don't have to stop there. You could also mix and match the JSON grammar elements with the additional "proper YAML" ones - including comments.

So this means any* software that accepts a YAML config would also accept the config as JSON or JSON-with-comments instead. No ecosystem bootstrapping necessary!

(*or almost any, as long as they don't use dicts with non-string keys)

Re: YAML document from hell (2023)

#129

Post by imglorp »

microtherion wrote: post #72
phpnode wrote: post #59

Earlier quoted context omitted.

Whoever thought supporting sexagesimal numbers was a good idea needs to spend some extended time away from their computer to reflect on what they’ve done

Presumably that was to support time values.

Does anyone do it that way?

Re: YAML document from hell (2023)

#130

Post by illusive4080 »

natebc wrote: post #89
bertman wrote: post #9

Discussion from 3 years ago, when this was originally posted: https://news.ycombinator.com/item?id=34351503 , 566 points, 358 comments

I think this article gets posted about every quarter.

I think it shows that there is a persistent dislike of yaml. I would like to read about the history of why yaml became so popular, despite all its flaws.
Post reply on HN