4 ms·

Yaml is total garbage. I’m not sure what is best, but it ain’t yaml. The Norway problem is unforgivable.

yboris 3y ago
"The Norway Problem" - had to look it up: https://www.bram.us/2022/01/11/yaml-the-norway-problem/ https://www.bram.us/2022/01/11/yaml-the-norway-problem/ Norway abbreviates to "NO" which YAML parses as "false"
- Dylan16807 3y ago
  They fixed it a long time ago... except half the implementations haven't updated.
  - zaps 3y ago
    Correct. It’s not YAML’s fault that the parsers haven’t caught up to its fixes.
    - eviks 3y ago
      but it is YAML's fault that it introduced this silly mistake in the first place
    - miffy900 3y ago
      No it's YAML's fault - the fact that type coercion was once part of the serialization spec and not part of an adjacent schema spec is a tragic mistake. Now there's a bunch of outdated parsers that exhibit the issue and some that have it fixed. Meaning even more inconsistency and frustration. In an ideal world, YAML just shouldn't exist.
mianos 3y ago
NO it's not, or False it's not or Not "NO". Ok you win. What a joke of a configuration language.
throwawaaarrgh 3y ago
Yaml is a great data serialization format. The "Norway problem" is not a format problem, it is a PEBKAC.
- Spivak 3y ago
  The norway problem is way overstated, people didn't learn YAMLs reserved words and got mad when it did what it said on the tin. If you know the type specify the type and YAML will happily err when you put a square peg in a round hole. Better yet actually validate the types when you ingest a document! Pfft who would bother with that? Recent versions of Ansible will now force you to do it right and not accept numbers when it expects a string. I believe the Prometheus ecosystem does it as well. When it comes to config formats this is pretty reasonable. People are just primed to expect true/false to be reserved. --- enable_frobulator: yes use_thopojog: no This was also the issue presented in the OP where they were mad that their version which is a string was interpreted as a number because it wasn't in quotes. Like I don't know how you expected YAML to fix that for you. If you don't quote a number in TOML it'll also be wrong.
xelxebar 3y ago
Oof. That's YAML 1.1. Need to use a 1.2 loader, which should have much better defaults around types. No more Norway problem unless explicitly opted into. We should badger^Wencourage our libraries to stop relying on a spec that's 14 years and multiple versions out of date.
alkonaut 3y ago
Even having any type coercion is a huge mistake. A true/false shouldn’t accept 0 or “false” with quotes or False with a capital f. It should be true or false. A single line string should accept one kind of quotes and one way of escaping. Similarly in xml it’s a curse that <Foo><Bar>1</Bar></Foo> and <Foo Bar=”1” /> are semantically the same but considered different in most systems. Just avoid ambiguity and make it impossible to face a choice. The same semantic meaning should have one expression.
globular-toast 3y ago
Accepting a boolean from a user config when you expected a string is unforgivable...

"The Norway Problem" - had to look it up: https://www.bram.us/2022/01/11/yaml-the-norway-problem/ https://www.bram.us/2022/01/11/yaml-the-norway-problem/ Norway abbreviates to "NO" which YAML parses as "false"

Dylan16807 3y ago
They fixed it a long time ago... except half the implementations haven't updated.
- zaps 3y ago
  Correct. It’s not YAML’s fault that the parsers haven’t caught up to its fixes.
  - eviks 3y ago
    but it is YAML's fault that it introduced this silly mistake in the first place
  - miffy900 3y ago
    No it's YAML's fault - the fact that type coercion was once part of the serialization spec and not part of an adjacent schema spec is a tragic mistake. Now there's a bunch of outdated parsers that exhibit the issue and some that have it fixed. Meaning even more inconsistency and frustration. In an ideal world, YAML just shouldn't exist.

mianos 3y ago

NO it's not, or False it's not or Not "NO". Ok you win. What a joke of a configuration language.

throwawaaarrgh 3y ago

Yaml is a great data serialization format. The "Norway problem" is not a format problem, it is a PEBKAC.

Spivak 3y ago
The norway problem is way overstated, people didn't learn YAMLs reserved words and got mad when it did what it said on the tin. If you know the type specify the type and YAML will happily err when you put a square peg in a round hole. Better yet actually validate the types when you ingest a document! Pfft who would bother with that? Recent versions of Ansible will now force you to do it right and not accept numbers when it expects a string. I believe the Prometheus ecosystem does it as well. When it comes to config formats this is pretty reasonable. People are just primed to expect true/false to be reserved. --- enable_frobulator: yes use_thopojog: no This was also the issue presented in the OP where they were mad that their version which is a string was interpreted as a number because it wasn't in quotes. Like I don't know how you expected YAML to fix that for you. If you don't quote a number in TOML it'll also be wrong.

xelxebar 3y ago

Oof. That's YAML 1.1. Need to use a 1.2 loader, which should have much better defaults around types. No more Norway problem unless explicitly opted into. We should badger^Wencourage our libraries to stop relying on a spec that's 14 years and multiple versions out of date.

alkonaut 3y ago

Even having any type coercion is a huge mistake. A true/false shouldn’t accept 0 or “false” with quotes or False with a capital f. It should be true or false. A single line string should accept one kind of quotes and one way of escaping. Similarly in xml it’s a curse that <Foo><Bar>1</Bar></Foo> and <Foo Bar=”1” /> are semantically the same but considered different in most systems. Just avoid ambiguity and make it impossible to face a choice. The same semantic meaning should have one expression.

globular-toast 3y ago

Accepting a boolean from a user config when you expected a string is unforgivable...