5 ms·

YAML? That's Norway Problem

al_borland 5mo ago
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.
rpreetha 5mo ago
Was backward compatibility the main reason YAML kept these implicit conversions for so long, or was there a stronger usability argument originally?
nalekberov 5mo ago
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.
- gfody 5mo ago
  https://ohyaml.wtf https://ohyaml.wtf
- deepsun 5mo ago
  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.
  - iririririr 5mo ago
    You may be on to something. Imagine Yaml only in the editor. but stored (and code reviews consequently) are .property style.
    - deepsun 5mo ago
      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.
      - iririririr 5mo ago
        ide doesnt save you from having the yaml in the wrong level. tried to look at a cloudinit file? it's pure insanity.
- Bolwin 5mo ago
  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/ https://maml.dev/
  - ThunderSizzle 5mo ago
    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</> </>  <spec> <version>1</> <author>Anton Medvedev</> </>  <examples> <item> <name>JSON</> <born>2001</> </> <item> <name>MAML</> <born>2025</> </> </> <notes> This is a multiline raw strings. Keeps formatting as-is. </>
    - eviks 5mo ago
      This is still noisy, wasting 3 symbols to end where an invisible line end would suffice
      - ThunderSizzle 5mo ago
        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.
    - tremon 5mo ago
      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.
      - 5mo ago
- simoncion 5mo ago
  > 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.
- DeathArrow 5mo ago
  >You are literally one missing tab away from breaking your entire configuration file. Isn't this true for Python, too?
  - simoncion 5mo ago
    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.
- xigoi 5mo ago
  > 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?
  - hexfran 5mo ago
    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
    - simoncion 5mo ago
      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.
  - nalekberov 5mo ago
    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.
    - xigoi 5mo ago
      I’d just like to know what kind of workflow you have that causes indentation to randomly change in your files.
      - simoncion 5mo ago
        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.)
bfung 5mo ago
Really? Putting quotes around strings is called escaping now? One workaround is to escape the string, like this: countries: - DE - FR - "NO" - PL - RO Comon, it’s 2026, yeah yaml’s design can lead to odd type casts, but a whole essay on this? Keep it under 140 chars pls.
- somat 5mo ago
  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.
tonetheman 5mo ago
[dead]
JSR_FDED 5mo ago
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.
- Insanity 5mo ago
  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.
- vrighter 5mo ago
  computers find yaml hard to parse too :)
- rixed 5mo ago
  That was the initial intended use case for Python to be a configuration language.
  - JSR_FDED 5mo ago
    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 :-)
    - rixed 5mo ago
      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)
- cornell532 5mo ago
  “Explicit is better than implict.” —PEP 8
jiggunjer 5mo ago
I'd say cue is nicer, but the tooling available is even less mature.
unscaled 5mo ago
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").
salzsax 5mo ago
[dead]
SeanSullivan86 5mo ago
Reminds me of some enum at my current employer, where all the US states have 2 letter codes, except Idaho is spelled out fully.
DeathArrow 5mo ago
I find JSON better for serialization/deserialization. It's a bit tedious to write by hand but who writes JSON by hand?
- procaryote 5mo ago
  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
7734128 5mo ago
This was probably the best written text I've read this year.
kayson 5mo ago
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.
- eviks 5mo ago
  Like this https://hitchdev.com/strictyaml/ https://hitchdev.com/strictyaml/?

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.

rpreetha 5mo ago

Was backward compatibility the main reason YAML kept these implicit conversions for so long, or was there a stronger usability argument originally?

nalekberov 5mo ago

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.

gfody 5mo ago
https://ohyaml.wtf https://ohyaml.wtf
deepsun 5mo ago
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.
- iririririr 5mo ago
  You may be on to something. Imagine Yaml only in the editor. but stored (and code reviews consequently) are .property style.
  - deepsun 5mo ago
    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.
    - iririririr 5mo ago
      ide doesnt save you from having the yaml in the wrong level. tried to look at a cloudinit file? it's pure insanity.
Bolwin 5mo ago
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/ https://maml.dev/
- ThunderSizzle 5mo ago
  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</> </>  <spec> <version>1</> <author>Anton Medvedev</> </>  <examples> <item> <name>JSON</> <born>2001</> </> <item> <name>MAML</> <born>2025</> </> </> <notes> This is a multiline raw strings. Keeps formatting as-is. </>
  - eviks 5mo ago
    This is still noisy, wasting 3 symbols to end where an invisible line end would suffice
    - ThunderSizzle 5mo ago
      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.
  - tremon 5mo ago
    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.
    - 5mo ago
simoncion 5mo ago
> 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.
DeathArrow 5mo ago
>You are literally one missing tab away from breaking your entire configuration file. Isn't this true for Python, too?
- simoncion 5mo ago
  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.
xigoi 5mo ago
> 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?
- hexfran 5mo ago
  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
  - simoncion 5mo ago
    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.
- nalekberov 5mo ago
  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.
  - xigoi 5mo ago
    I’d just like to know what kind of workflow you have that causes indentation to randomly change in your files.
    - simoncion 5mo ago
      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.)

bfung 5mo ago

Really? Putting quotes around strings is called escaping now? One workaround is to escape the string, like this: countries: - DE - FR - "NO" - PL - RO Comon, it’s 2026, yeah yaml’s design can lead to odd type casts, but a whole essay on this? Keep it under 140 chars pls.

somat 5mo ago
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.

tonetheman 5mo ago

[dead]

JSR_FDED 5mo ago

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.

Insanity 5mo ago
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.
vrighter 5mo ago
computers find yaml hard to parse too :)
rixed 5mo ago
That was the initial intended use case for Python to be a configuration language.
- JSR_FDED 5mo ago
  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 :-)
  - rixed 5mo ago
    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)
cornell532 5mo ago
“Explicit is better than implict.” —PEP 8

jiggunjer 5mo ago

I'd say cue is nicer, but the tooling available is even less mature.

unscaled 5mo ago

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

salzsax 5mo ago

[dead]

SeanSullivan86 5mo ago

Reminds me of some enum at my current employer, where all the US states have 2 letter codes, except Idaho is spelled out fully.

DeathArrow 5mo ago

I find JSON better for serialization/deserialization. It's a bit tedious to write by hand but who writes JSON by hand?

procaryote 5mo ago
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

7734128 5mo ago

This was probably the best written text I've read this year.

kayson 5mo ago

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.

eviks 5mo ago
Like this https://hitchdev.com/strictyaml/ https://hitchdev.com/strictyaml/?