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…
Fear and Loathing in YAML
31–40 of 107 posts
Re: Fear and Loathing in YAML
#32> 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 .
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
#33Re: Fear and Loathing in YAML
#34Earlier 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).
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
#35I 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
#36TOML 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…
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
#37I 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?
[0] https://dhall-lang.org/ [1] https://github.com/dhall-lang/dhall-kubernetes
Re: Fear and Loathing in YAML
#38I 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
#39It'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)