Live data from Hacker News

Fear and Loathing in YAML

chrisshort.net

31–40 of 107 posts

Re: Fear and Loathing in YAML

#31
post #24
post #13

Earlier quoted context omitted.

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…

I would be very interested in an experiment in which participants are required to write Kubernetes manifests in YAML or TOML, and what the analysis suggests they prefer (after controlling for the right set of variables). I don’t like YAML, but TOML stops being nice very quickly as the size or complexity of the data increases IMO.

Re: Fear and Loathing in YAML

#32
post #29

> 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 .

It didn't used to be: https://yaml.org/spec/history/2001-08-01.html

However I must admit some surprise at learning that even before 2010 they changed to the recursive acronym. I was still calling it yet another markup language even back then. I thought anything back then was yet another if it started with ya, like YaST from SuSE (yet another setup tool).

Re: Fear and Loathing in YAML

#33
The thing I don't like about YAML is the strict meaningful indentation. It's fine once you install an extension that won't let you do anything other than two spaces, but it's pretty horrific if you try to edit a yaml file in a virgin text editor when you aren't super familiar with the format, especially if you try to copy paste things.

Re: Fear and Loathing in YAML

#34
post #29

Earlier quoted context omitted.

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 .

It didn't used to be: https://yaml.org/spec/history/2001-08-01.html However I must admit some surprise at learning that even before 2010 they changed to the recursive acronym. I was still calling it yet another markup language even back then. I thought anything back then was yet another if it started with ya, like YaST from SuSE (yet another setup tool).

Wow I always thought it was "Yet Another Markup Language". It's crazy that they would change to be literally opposite of the original name.

From the wikipedia article:

> but it was then repurposed as YAML Ain't Markup Language, a recursive acronym, to distinguish its purpose as data-oriented, rather than document markup.

I mean couldn't it be both data-oriented and a markup language?

Re: Fear and Loathing in YAML

#35
I think I would genuinely be pretty happy with a well-supported extension of the JSON spec that allows comments. Even if it required an explicit start and end of the comment (/* ... */). I also can't say I want or need anchors/references from YAML, so I think that helps me be quite OK with using JSON.

I appreciate the challenges of writing JSON, but also think it can be easier to spot issues if you have an editor that's doing magic indentation based on the JSON. Give me comments to help the humans, and I'm sold.

Re: Fear and Loathing in YAML

#36
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…

I like TOML too, but speaking of footguns, there is one where it comes to serialization. If you have something like:

    struct Foo {
        int bar;
        Baz baz;
        int quux;
    }
... you can't naively serialize this like:

    [foo]
    bar = 5

    [foo.baz]
    ...

    quux = 6
because that makes `quux` a property of `foo.baz`, not of `foo`.

The serializer has to be smart enough to recognize that primitive fields have to be serialized before object fields. As a practical example, Rust's TOML library is not smart enough to do so, though it does at least detect when this would happen and fails with a runtime error. (The workaround is to change your type definition to reorder the fields yourself.)

Ref: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: Fear and Loathing in YAML

#37

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?

There's a Kubernetes plugin/package for Dhall [0] that can do this [1], it's very neat. I've played with it briefly, and whilst a tiny bit verbose (mostly as a function of the K8s specs themselves I suspect), the ability to have it validate everything before you even touched K8s was worth it imo.

[0] https://dhall-lang.org/ [1] https://github.com/dhall-lang/dhall-kubernetes

Re: Fear and Loathing in YAML

#38
sigh

I would like to mumble something about s-expressions and how this has been solved long ago but I lack the stamina after doing it so many times.

Let me go back to my job and my task of modifying a Helm chart which decided that string manipulation of yaml files is truly the way to go.

Re: Fear and Loathing in YAML

#39
Am I the only one who finds YAML much harder to write than JSON or XML?

It's not just the fact that I get the syntax for lists and maps confused all the damn time. The worst part is that I'm unable to use the keyboard shortcut for automatically formatting my document!

I love that keyboard shortcut! I hate being without it! I'm certain it represents more than half of my key presses in other languages!

I type a few characters and then I press the code formatting shortcut. That's what I do! That's my workflow!

I don't understand how people who work in whitespace-significant languages can stand being without it! ;-)

(I'm only half-joking - I do find it very frustrating)

Post reply on HN