Live data from Hacker News

Fear and Loathing in YAML

chrisshort.net

11–20 of 107 posts

Re: Fear and Loathing in YAML

#11
An interesting candidate in the other end of the spectrum is Dhall, https://dhall-lang.org. If I was working in one of the languages with current implementations I would no doubt try it out.

Edit: I will also add that dhall will export to YAML/JSON etc, however I'm not a fan on intermediary config file processing.

Re: Fear and Loathing in YAML

#12
post #7
post #2

Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file. I remember being pretty…

The biggest problem I find with YML is that whitespace matters, but merging tools usually are set to ignore whitespace. So git merge will say "no merge conflicts", but actually there were whitespace changes.

I don't think that's the default setting for git merge at least.

Re: Fear and Loathing in YAML

#13
post #6

TOML remains severely underrated, for some reason. It's easy to read, easy to write, trivial to map onto JSON, and refreshingly clear of footguns. There are comments! If you get to pick your format for a configuration language, start by trying to talk yourself out of TOML. You'll probably fail; I'm interested to hear if folks out there have examples of something TOML is bad at, because I didn't come up with any when…

Another comment brought up StrictYAML, and they have a good dissection of the problems with TOML[1].

Personally, after doing a few pyproject.toml files, I still find it confusing and awkward as soon as you get past simple headers and key-values.

TOML is like YAML, it translates to "jsonic" types, but JSON's virtue is that simple 1:1 mapping between syntax and data.

TOML and YAML both have non-obvious syntax and there's a layer of translation you have to do to understand what you're actually generating.

But I don't really want to generate a big blob of objects, arrays and such, I want to configure something. I think that's why none of these languages work very well.

[1]: https://hitchdev.com/strictyaml/why-not/toml/

Re: Fear and Loathing in YAML

#14
post #2

Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file. I remember being pretty…

XML master race!

Re: Fear and Loathing in YAML

#15
post #2

Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file. I remember being pretty…

I’m curious, do you recall what the specifics of the whitespace change were?

Re: Fear and Loathing in YAML

#17
post #12
post #7

Earlier quoted context omitted.

The biggest problem I find with YML is that whitespace matters, but merging tools usually are set to ignore whitespace. So git merge will say "no merge conflicts", but actually there were whitespace changes.

I don't think that's the default setting for git merge at least.

Maybe it's the merging tool I used?

Re: Fear and Loathing in YAML

#18
post #2

Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file. I remember being pretty…

Being a superset of JSON, YAML allows you to use braces for maps and square brackets for arrays instead of relying on indentation.

You can still omit quotes around strings, use comments and add trailing commas after the last element of collections.

A configuration file written in that style is actually pretty nice. I’ve never understood why people don’t use this.

Re: Fear and Loathing in YAML

#20
post #2

Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file. I remember being pretty…

Being a superset of JSON, YAML allows you to use braces for maps and square brackets for arrays instead of relying on indentation. You can still omit quotes around strings, use comments and add trailing commas after the last element of collections. A configuration file written in that style is actually pretty nice. I’ve never understood why people don’t use this.

But you can't put comments in JSON.

But you can write Python (or pretty much any other tool) and have it emitted as JSON.

Post reply on HN