YAML? That's Norway Problem(lab174.com)
lab174.com
YAML? That's Norway Problem
https://lab174.com/blog/202601-yaml-norway/
45 comments
Somehow my brain finds YAML hard to parse. JSON is easy but ugly. Lately I’ve just been using Python code in a module to initialize config settings. Initially it was just a lazy way to get started, but having the flexibility of an actual language is great when things evolve over time.
TBH that is what attracted me to Pulumi to manage IaC. My brain doesn’t find YAML appealing as a configuration language, and having a known fully-fledged language available makes life a bit easier.
That was the initial intended use case for Python to be a configuration language.
Really? I thought that was more the case for Lua. Which by the way is more happiness per line of code than most other languages :-)
Actually, I remembered having read that in an old interview in the early 2000s, but I can't retrieve it now so it's safe to assume that it's a false memory.
Lua was designed to be an extension language though (checked on wikipedia this time :-D)
Lua was designed to be an extension language though (checked on wikipedia this time :-D)
computers find yaml hard to parse too :)
“Explicit is better than implict.”
—PEP 8
—PEP 8
For yaml in the context of Ansible, this was recently fixed a little while back in v2.19.
They got more strict about booleans. For those who need/want the old behavior, ALLOW_BROKEN_CONDITIONALS can be set in the ansible.cfg or `is truthy` can be used for python-like version, but it becomes explicit vs being implied.
They got more strict about booleans. For those who need/want the old behavior, ALLOW_BROKEN_CONDITIONALS can be set in the ansible.cfg or `is truthy` can be used for python-like version, but it becomes explicit vs being implied.
YAML is the worst format.
You are literally one missing tab away from breaking your entire configuration file. Yet the industry keeps pushing it for the sake of “simplicity” - for small configurations sure, it’s fine, but many hundred lines of config entries? Good luck fixing it, if something goes wrong.
I still can’t get why software engineers suddenly started to hate XML.
You are literally one missing tab away from breaking your entire configuration file. Yet the industry keeps pushing it for the sake of “simplicity” - for small configurations sure, it’s fine, but many hundred lines of config entries? Good luck fixing it, if something goes wrong.
I still can’t get why software engineers suddenly started to hate XML.
Long time ago i thought .properties was bad, as it has no structure. But later I realized repeating full path to every config param is really good for readability, and code reviews.
The only thing I wish it had is @import-s from a separate files, that way we could split local/checkedin configs. YAML doesn't have @imports as well (only rudimentary from the same file), I have only seen them at HOCON.
The only thing I wish it had is @import-s from a separate files, that way we could split local/checkedin configs. YAML doesn't have @imports as well (only rudimentary from the same file), I have only seen them at HOCON.
You may be on to something.
Imagine Yaml only in the editor. but stored (and code reviews consequently) are .property style.
Imagine Yaml only in the editor. but stored (and code reviews consequently) are .property style.
IDE (like IntelliJ) can already do syntax coloring, autocompletion a even schema checking for known .properties. I don't see a reason in short names if I don't type them anyway, it's all autocompletion.
ide doesnt save you from having the yaml in the wrong level. tried to look at a cloudinit file? it's pure insanity.
Cause it's very verbose. A lot more syntax to break.
I personally think the best is one of the humanized json ones like https://maml.dev/
I personally think the best is one of the humanized json ones like https://maml.dev/
It wouldn't need to be if closing tags were allowed to be unnamed. For most cases, we can tell the closing tags easily enough for simpler files:
<project>MAML</>
<tags>
<item>minimal</>
<item>readable</>
</>
<!-- A simple nested object -->
<spec>
<version>1</>
<author>Anton Medvedev</>
</>
<!-- Array of objects -->
<examples>
<item>
<name>JSON</>
<born>2001</>
</>
<item>
<name>MAML</>
<born>2025</>
</>
</>
<notes>
This is a multiline raw strings.
Keeps formatting as-is.
</>But if closing tags are allowed to be unnamed, you are still one misplaced </> away from unrecognizably maiming the entire hierarchical structure, just like one incorrect indent can do in YAML.
Ultimately, what matters is the editing mode and not the data format. Good syntax highlighting and autocompletion goes a long way towards safely editing structured text, regardless of on-disk format.
Ultimately, what matters is the editing mode and not the data format. Good syntax highlighting and autocompletion goes a long way towards safely editing structured text, regardless of on-disk format.
You need to misplace a </> in a way that still produces a valid xml document. Just forgetting one or adding an extra one will throw an error.
Watch out, next thing you know you'll have reinvented S-expressions.
Which is really all we ever needed.
Which is really all we ever needed.
This is still noisy, wasting 3 symbols to end where an invisible line end would suffice
Fine. Then auto-closing tags? If you have a schema doc, you could do that. If you are writing free-form, then I'd definitely be complicated...?
I still see that better than YAML's indentation problem. Relying solely on indentation is a nightmare.
I still see that better than YAML's indentation problem. Relying solely on indentation is a nightmare.
> You are literally one missing tab away from breaking your entire configuration file.
Not if you use the "flow" style. The "flow" style makes the syntax almost tolerable. But, if you do that:
a) You don't get to use all of YAML. I remember that the '|' construction could not be used, and I believe that there was at least one other feature that was unavailable.
b) Get ready to get turbofucked when some YAML-handling library writes out your config file in "block" style, putting you right back in Indentation Hell.
After having worked with both professionally for many years, I'd say that I hate JSON and YAML just about equally.
Not if you use the "flow" style. The "flow" style makes the syntax almost tolerable. But, if you do that:
a) You don't get to use all of YAML. I remember that the '|' construction could not be used, and I believe that there was at least one other feature that was unavailable.
b) Get ready to get turbofucked when some YAML-handling library writes out your config file in "block" style, putting you right back in Indentation Hell.
After having worked with both professionally for many years, I'd say that I hate JSON and YAML just about equally.
> You are literally one missing tab away from breaking your entire configuration file.
In JSON, you’re one curly brace away from breaking your entire configuration file. How is that different?
In JSON, you’re one curly brace away from breaking your entire configuration file. How is that different?
JSON isn’t ideal either, however missing curly braces are much easier to fix than figuring out where you misaligned entries without going through entire config file.
I’d just like to know what kind of workflow you have that causes indentation to randomly change in your files.
Do you not use an editor that permits you perform at least one operation that would alter the indentation level of multiple lines all at once? Separate from that, have you never fat-fingered the tab, space, backspace or delete keys? Never deleted one too many whitespace tokens when cleaning up an inadvertent or misdirected paste? (If you've never done that, then kudos to you... but in two to six decades, it's certain to happen to you annoyingly often.)
> Do you not use an editor that permits you perform at least one operation that would alter the indentation level of multiple lines all at once?
Yes, but I don’t just randomly perform the operation when I don’t want to change the indentation.
> Separate from that, have you never fat-fingered the tab, space, backspace or delete keys?
When I’m in insert mode, I look at what I’m writing, so I immediately undo any such accidental edit. Outside insert mode, it’s hard to accidentally change indentation.
> Never deleted one too many whitespace tokens when cleaning up an inadvertent or misdirected paste?
I use indentation-preserving paste, so… no?
Yes, but I don’t just randomly perform the operation when I don’t want to change the indentation.
> Separate from that, have you never fat-fingered the tab, space, backspace or delete keys?
When I’m in insert mode, I look at what I’m writing, so I immediately undo any such accidental edit. Outside insert mode, it’s hard to accidentally change indentation.
> Never deleted one too many whitespace tokens when cleaning up an inadvertent or misdirected paste?
I use indentation-preserving paste, so… no?
Ah. You're The One. Got it.
Well, I'll likely be long dead once time's erosion of your body's self-repair machinery has destroyed your ability to be The One. Given that, please do accept this package containing my condolences for your loss. Time's insults are profoundly cruel and unjust.
Well, I'll likely be long dead once time's erosion of your body's self-repair machinery has destroyed your ability to be The One. Given that, please do accept this package containing my condolences for your loss. Time's insults are profoundly cruel and unjust.
I guess the missing brace is a scope delimiter and easy to notice if missing, while the tab is an indentation marker and much harder to spot, and might get you into an invalid state but still parse correctly, just not doing what it was meant to do
Additionally, file segments [0] written with a grammar that uses scope-defining character pairs survive round trips through email, chat, the paste buffers of a series of less-than-maximally-careful coworkers, etc. etc. etc. much, much better than those written with a grammar that uses whitespace to define scope.
<strike>Ask me how I know.</strike>
[0] sections? snippets? fragments? Hopefully you get what I'm trying to say here.
<strike>Ask me how I know.</strike>
[0] sections? snippets? fragments? Hopefully you get what I'm trying to say here.
>You are literally one missing tab away from breaking your entire configuration file.
Isn't this true for Python, too?
Isn't this true for Python, too?
It is, yes. And unlike YAML, there's no official way to use a syntax that doesn't use whitespace to define scope.
Python's whitespace-defines-scope syntax is the reason I won't use it unless I have no other choice. If it weren't for that -IMO- extremely poor design choice, I'd consider it to be a decent language. [0]
[0] Yes, some people think this feature of Python is fine. I'm not one of them. Whether or not you think this feature is fine is a matter of taste.
Python's whitespace-defines-scope syntax is the reason I won't use it unless I have no other choice. If it weren't for that -IMO- extremely poor design choice, I'd consider it to be a decent language. [0]
[0] Yes, some people think this feature of Python is fine. I'm not one of them. Whether or not you think this feature is fine is a matter of taste.
I wish there were a "strict" yaml. Another subset a la json, where you don't have nonsense like no === false, but "no" does not, but you also get the block style which to me is easier to read and write. I don't mind requiring quotes for strings. Modern IDEs make it easy enough and it removes ambiguity.
Like this https://hitchdev.com/strictyaml/?
Was backward compatibility the main reason YAML kept these implicit conversions for so long, or was there a stronger usability argument originally?
I'd say cue is nicer, but the tooling available is even less mature.
Really? Putting quotes around strings is called escaping now?
One workaround is to escape the string, like this:
countries:
- DE
- FR
- "NO"
- PL
- RO
Also YAML fixed this in (checks spec) 2009 with the 1.2 version. If projects want to keep using old spec that's not yamls fault.
I have doubts about the over all utility of yaml. I am not sure how readable it is over well formed json. and my main exposure to it is ansible which suffers from the inner platform effect where in order to save us from programming a programming language is jammed into a non programming language(usually XML but in this case YAML) and every one is more miserable for the experience. But complaining about a thing that is fixed is wierd.
I have doubts about the over all utility of yaml. I am not sure how readable it is over well formed json. and my main exposure to it is ansible which suffers from the inner platform effect where in order to save us from programming a programming language is jammed into a non programming language(usually XML but in this case YAML) and every one is more miserable for the experience. But complaining about a thing that is fixed is wierd.
I find JSON better for serialization/deserialization. It's a bit tedious to write by hand but who writes JSON by hand?
Write json5, which gives you most of the brevity of yaml without the terrible ideas
I find even plain json easier to write than yaml. Especially when you factor in the scope of mistakes. Tiny mistakes can completely break the structure of a yaml document in ways that are still valid yaml. With json I'll catch that because auto-indenting will follow the actual structure
I find even plain json easier to write than yaml. Especially when you factor in the scope of mistakes. Tiny mistakes can completely break the structure of a yaml document in ways that are still valid yaml. With json I'll catch that because auto-indenting will follow the actual structure
Reminds me of some enum at my current employer, where all the US states have 2 letter codes, except Idaho is spelled out fully.
OP mentions backward compatibility and popular YAML libraries as the reason why the "Norway problem" is still an issue, but I'm a little bit doubtful about this explanation.
It's been 10 years, if not more, since I've seen YAML configuration files using "yes/no" or "on/off". Even back in the day, these alternative boolean values were never extremely popular: the community more or less settled on true/false.
The libraries issue is real, but my issue is with the word "popular". These are libraries that used to be very popular, and kinda stuck on as the default, even though most of them semi-abandoned and (at least in my opinion) shouldn't really be used by any new project.
PyYAML's last major release was in 2021, and it's only seen security fixes since then. Even the last major release in 2021 was only a major release becasue Python 2.7 support was removed. Before that there were some API changes in 5.1 released in 2019 (only because the PyYAML defaults have been ridiculously insecure and everyone has been complaining about this for years), and between 2008 and 2019 there were barely any worthwhile changes. tl;dr: PyYAML has been in maintenance mode since 2008.
Libyaml (which PyYAML is based on) hasn't seen a new release since 2020, and while it introduced some YAML 1.2 support, the development pace on this library has been glacial since 2009. Between 2009 and 2020, the project had 3 commits touching actual code per year on average, and since then the number went down to 1 commit on average.
It's a sad state that both libyaml and PyYAML are part of the official YAML project, but hasn't budged forward in supporting YAML 1.2. There is something to be said about open-source project being feature complete and requiring only light maintenance, but if they don't support the latest major YAML spec version that was released all the way back in 2009, I don't think we can call them feature-complete.
There are newer libraries out there for all these languages that support 1.2, are more well-maintained and often offer better and safer API, like libfyaml for C, yaml-cpp for C++, ruaemel for Python and goccy/yaml for Go (not the same as the original go-yaml, does support most of YAML 1.2, but has strangely chosen to keep the "Norway booleans").
It's been 10 years, if not more, since I've seen YAML configuration files using "yes/no" or "on/off". Even back in the day, these alternative boolean values were never extremely popular: the community more or less settled on true/false.
The libraries issue is real, but my issue is with the word "popular". These are libraries that used to be very popular, and kinda stuck on as the default, even though most of them semi-abandoned and (at least in my opinion) shouldn't really be used by any new project.
PyYAML's last major release was in 2021, and it's only seen security fixes since then. Even the last major release in 2021 was only a major release becasue Python 2.7 support was removed. Before that there were some API changes in 5.1 released in 2019 (only because the PyYAML defaults have been ridiculously insecure and everyone has been complaining about this for years), and between 2008 and 2019 there were barely any worthwhile changes. tl;dr: PyYAML has been in maintenance mode since 2008.
Libyaml (which PyYAML is based on) hasn't seen a new release since 2020, and while it introduced some YAML 1.2 support, the development pace on this library has been glacial since 2009. Between 2009 and 2020, the project had 3 commits touching actual code per year on average, and since then the number went down to 1 commit on average.
It's a sad state that both libyaml and PyYAML are part of the official YAML project, but hasn't budged forward in supporting YAML 1.2. There is something to be said about open-source project being feature complete and requiring only light maintenance, but if they don't support the latest major YAML spec version that was released all the way back in 2009, I don't think we can call them feature-complete.
There are newer libraries out there for all these languages that support 1.2, are more well-maintained and often offer better and safer API, like libfyaml for C, yaml-cpp for C++, ruaemel for Python and goccy/yaml for Go (not the same as the original go-yaml, does support most of YAML 1.2, but has strangely chosen to keep the "Norway booleans").
This was probably the best written text I've read this year.