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

Fear and Loathing in YAML

chrisshort.net

Post reply on HN
Print view View original

21–30 of 107 posts

Re: Fear and Loathing in YAML

#21

Post by smitty1e »

samatman wrote: 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…

In the future, everyone will write a markup language that will be the flavor of the quarter-hour, begetting a cottage industry of translation tools.

Re: Fear and Loathing in YAML

#22

Post by brundolf »

I wonder why IDE-enforced markup-schemas haven't caught on. Like a static type system for your markup (i.e. Kubernetes could declare your "types" and your editor could ensure the config fits them).

VSCode has something along these lines for JSON - at least on its own settings configuration - but somehow the approach hasn't become prevalent. Are we lacking a standard? Motivation?

Re: Fear and Loathing in YAML

#23

Post by andrenth »

smitty1e wrote: post #20
andrenth wrote: post #18

Earlier quoted context omitted.

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.

I think you misunderstood. What I meant is that you can put comments in YAML but use JSON-like braces instead of relying on indentation.

Re: Fear and Loathing in YAML

#24

Post by saghm »

ben509 wrote: post #13
samatman wrote: 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…

IMHO the arguments in your link aren't particularly convincing. The three main points seem to be verbosity (defined in terms of total number of characters for a given file, which is not nearly as important to me as readability), not having indentation be significant (which might be downside to a Python programmer but feels like a win to me), and having explicit syntax to distinguish between types (e.g. strings being quoted, which is preferable to me, since it makes them stand out as values compared to the keys). If these are the strongest arguments against TOML, I find myself fairly convinced that TOML is probably the format I'd like to use most even though I was I different towards it before clicking the link.

Re: Fear and Loathing in YAML

#25

Post by samatman »

ben509 wrote: post #13
samatman wrote: 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…

That's not a bad argument against using TOML, and I'm inclined to agree that TOML is more verbose than it has to be for heavily-nested maps-of-maps-of-maps.

Which you can pretend is a strength, since I consider doing that an anti-pattern. But it is a valid critique.

However, the TOML they offer as a comparison to the StrictYAML is probably auto-generated (they do say "serialized TOML equivalent") and it's quite a bit noisier than it has to be.

TOML deliberately has a couple of ways of writing arrays, and a one-line short format for maps: you're supposed to alternate these, and this technique could eliminate most of the repetition in that particular file.

I still wouldn't choose TOML for a complex tree of user stories where the keys are all long strings of English: that's an example of the kind of thing where you might talk yourself out of using it!

Here's the counterpoint I want to offer: stories of YAML "configuration languages" escaping confinement and becoming headache-inducing repositories of monstrous complexity are practically cliche at this point.

Part of why that is, is that you don't pay for that complexity "up front": It's just a nice list! It's easy to read!

I would add one thing to TOML if I could: it should default to a string for the value part of a key-value pair, if it can't make anything else. So

   my_val = 42
Makes a number,

   my_string = "42"
Gives you a string, and

   my_regex = ^\"(\\.|[^\"])*\"
lets you handle regexes without the obnoxious double-quoting problem, while removing a lot of the verbosity and ceremony from the format.

Re: Fear and Loathing in YAML

#26

Post by djhaskin987 »

> there was something off-putting about YAML. It was a markup language claiming not to be a markup language.

The acronym literally stands for "Yet Another Markup Language".

Edit: To comment something less pedantic, the article doesn't really go into anything specific it doesn't like about it. It's sort of like when my brother comments about how awful the vim home web page looks. It's still a good web page. I don't know why people are commenting about aesthetics in YAML if they can't pinpoint a particular functionality problem.

That said, I'm not blind to the many warts and weird edge cases and dozens of different ways you can specify a string in YAML. I hope something more elegant comes along that's still not as draconian as JSON (simple, elegant, hard to write strings, no comments).

Re: Fear and Loathing in YAML

#27

Post by cferr »

baq wrote: post #8

I’d say yaml itself is the smaller part of the problem. The real fun starts when its obvious shortcomings (for use cases it’s being attempted to fulfill) are being papered over with jinja2, code in nondescript languages embedded in string values and css-like composition rules for multiple files.

You mean like with Ansible?

Re: Fear and Loathing in YAML

#28

Post by balfirevic »

andrenth wrote: post #18
pjbk wrote: 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.

Except for omitting quotes around strings, that sounds very similar to json5 [0].

[0] - https://json5.org/

Re: Fear and Loathing in YAML

#29

Post by tofflos »

djhaskin987 wrote: post #26

> there was something off-putting about YAML. It was a markup language claiming not to be a markup language. The acronym literally stands for "Yet Another Markup Language". Edit: To comment something less pedantic, the article doesn't really go into anything specific it doesn't like about it. It's sort of like when my brother comments about how awful the vim home web page looks. It's still a good web page. I don't kn…

YAML (a recursive acronym for "YAML Ain't Markup Language")

Source https://en.wikipedia.org/wiki/YAML. Also https://yaml.org/spec/1.2/spec.html.

Re: Fear and Loathing in YAML

#30

Post by slifin »

In a world where there's only a few primitive types no one can share uuids or dates across the wire without both sides knowing which fields are dates or uuids ahead of time

JSON is too simple we need more primitive types and an extensible data notation to formalise data sharing of unknown types

Post reply on HN