YAML? That's Norway Problem

https://lab174.com/blog/202601-yaml-norway/

38 43 2 months ago

al_borland• 2 months 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• 2 months ago

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

nalekberov2• 2 months 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• 2 months ago

https://ohyaml.wtf

deepsun2• 2 months 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.

iririririr2• 2 months ago

You may be on to something.

Imagine Yaml only in the editor. but stored (and code reviews consequently) are .property style.

Bolwin• 2 months 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/

ThunderSizzle2• 2 months 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</>
  </>
  
  <!-- 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.
  </>

simoncion5• 2 months 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.

DeathArrow2• 2 months ago

You are literally one missing tab away from breaking your entire configuration file.

Isn't this true for Python, too?

simoncion5• 2 months 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.

xigoi3• 2 months 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• 2 months 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

nalekberov2• 2 months 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.

bfung• 2 months 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• 2 months 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.

JSR_FDED2• 2 months 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• 2 months 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• 2 months ago

computers find yaml hard to parse too :)

rixed2• 2 months ago

That was the initial intended use case for Python to be a configuration language.

JSR_FDED2• 2 months 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 :-)

cornell532• 2 months ago

“Explicit is better than implict.”

—PEP 8

jiggunjer• 2 months ago

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

unscaled• 2 months 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").

SeanSullivan86• 2 months 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.

DeathArrow2• 2 months ago

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

procaryote2• 2 months 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• 2 months ago

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

kayson• 2 months 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.

eviks2• 2 months ago

Like this https://hitchdev.com/strictyaml/?

YAML? That's Norway Problem

Related Stories