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

111–120 of 144 posts

Re: YAML document from hell (2023)

#111

Post by Diti »

Y-bar wrote: post #54
al_borland wrote: post #2

The Norway problem drives me a bit nuts. In a lot of the Ansible documentation, yes/no are used instead of true/false. When seeing this in the official docs, I used it, figuring this was the preferred convention in Ansible. These days it now throws warnings or lint errors, so I’m updating it all over the places as I find it. Yet the Ansible documentation still commonly uses it.

Has this really been a problem in the last ten years? Version 1.2 of the spec (if I recall) fixed it in 2009.

Only if you use Kubernetes, because it’s YAML 1.1 all the way.

Re: YAML document from hell (2023)

#112

Post by telliott1984 »

I think I've tried to start using anchors at least once every year or so when I get annoyed with a particularly repetitive file. Never managed to get my head around it. Just seems so shoe-horned in and if anything makes the document harder to follow.

Re: YAML document from hell (2023)

#113

Post by speed_spread »

Ajedi32 wrote: post #88
speed_spread wrote: post #85

Earlier quoted context omitted.

In JSON I often end up recreating XML attributes equivalent for metadata fields and using custom prefixes to differentiate those fields from actual data. I find it's nice the data/metadata separation at the language level.

Can you give an example of metadata you would put in a config file that isn't configuration and isn't a comment?

Metadata is less useful in a config file since it's all static data. But for something more dynamic (messaging, persistence) attributes can be used for Time-To-Live, object class, source, signature, etc.

Re: YAML document from hell (2023)

#114

Post by jrmg »

Amazed that there are no comments yet mentioning HUML:

https://news.ycombinator.com/item?id=45335129

It was on the front page yesterday!

Human-oriented Markup Language

HUML is a simple, strict, serialization language for documents, datasets, and configuration. It prioritizes strict form for human-readability. It looks like YAML, but tries to avoid its complexity, ambiguity, and pitfalls.

Re: YAML document from hell (2023)

#115

Post by rajer »

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.

As a total noob who had to work with yaml to write pipelines for ADO over my summer internship, I didn't seem to encounter any of these oddities, nearly everything I worked with was wrapped in quotations.

Re: YAML document from hell (2023)

#116

Post by pavon »

com2kid wrote: post #93
lucideer wrote: post #53

Earlier quoted context omitted.

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…

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 many other formats, the syntax for nesting has a visual appearance that matches the logical nesting. TOML does not. You have to maintain a mental model of the data structure, and slot the flat syntax into that structure.

Furthermore, there are multiple ways to express the same thing like

  [fruit.apple]
  color = "red"
or

  [fruit]
  apple.color = "red"
It isn't always obvious which approach is more appropriate for a task, and mixing them creates a big mess.

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

Re: YAML document from hell (2023)

#117

Post by larkost »

If anyone wants to raid some code for simpler YAML, I wrote a version for the RethinkDB tests a long time ago:

https://github.com/rethinkdb/rethinkdb/blob/main/test/common...

The problem I was trying to solve was that our tests involved a lot of things that looked like dicts (in fact they were), so my YAML-like parser stops parsing things when it looks like we have hit test code. This took out so much escaping, and made it easy to copy-paste tests into a REPL when you were working on the test (and vise-versa).

So it looks like YAML, but without most of the features, and without the footguns.

Re: YAML document from hell (2023)

#118

Post by lucideer »

munificent wrote: post #102
lucideer wrote: post #77

Earlier quoted context omitted.

> It's because JSON doesn't have comments. This is a big plus but JSON5 has pretty widespread language library support - probably equal to that of YAML tbh (e.g. Swift has native JSON5 support, I don't know that anyone natively supports YAML). Any reason not to opt for it here?

I believe JSON5 didn't exist when we first wrote pub. If it did, it certainly wasn't widely known. Obviously, migrating to it now when there are thousands and thousands of packages and dozens of tools all reading pubspecs would be much more trouble than it's worth.

Understandable. I just checked & JSON5 was just 1 year later but even then it would've taken a lot longer to gain sufficient traction to be well supported.

Re: YAML document from hell (2023)

#119

Post by lucideer »

Diti wrote: post #90
lucideer wrote: post #77

Earlier quoted context omitted.

> It's because JSON doesn't have comments. This is a big plus but JSON5 has pretty widespread language library support - probably equal to that of YAML tbh (e.g. Swift has native JSON5 support, I don't know that anyone natively supports YAML). Any reason not to opt for it here?

Most protocols defined in RFCs require the use of regular JSON. You don’t have a choice.

Not sure what context you're referring to but we're discussing configuration file formats, not data transports, so I doubt that would be a frequent issue.

Re: YAML document from hell (2023)

#120

Post by baby »

com2kid wrote: post #93
lucideer wrote: post #53

Earlier quoted context omitted.

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…

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!

toml is just not human friendly unless you're just using a super simple object with as little nesting as possible. As soon as you increase the nesting you need yaml or json
Post reply on HN