YAML: The Norway Problem (2022)
111 comments
·April 12, 2025anvandare
"The limits of my keyboard mean the limits of my programming language."
If only they had had ⊥ and ⊤ somewhere on their keys to work with Booleans directly while designing the languages. In another branch of history, perchance.[1]
[1] https://en.wikipedia.org/wiki/APL_(programming_language)#/me...
#/media/File:APL-keybd2.svg){kind=link}
tossandthrow
⊥ and ⊤ is not entirely congruent to false and true.
Boolean and propositional logic is not the same.
whacko_quacko
Pandas has a Nigeria problem, where NA -> NaN.
It's not that bad, because you can explicitly turn that behavior off, but ask me how I know =(
orangewindies
That's a Namibia problem, Nigeria is NG.
trueismywork
How?
pkkm
Programming with string templates, in a highly complex and footgun-rich markup language, is one of the things I find most offputting about the DevOps ecosystem.
sph
I believe Satan itself decided to mix YAML, Jinja and Turing-complete logic when it created Ansible. It truly is the sendmail of the modern era.
weinzierl
Perl has a Poland Problem. The customary file extension for Perl files is *.pl. This worked well until Apache introduced content negotiation and the convention to add a language code as file extension. It had index.html.en, index.html.de, for example.
index.html.pl is where the problem started and the reason why the officially recommended file extension for Perl files used to be (still is?) *.plx.
I don't have the Camel book at hand, but Randal Schwartz's Learning Perl 5th edition says:
"Perl doesn't require any special kind of filename or extension, and it's better not to use an extension at all. But some systems may require an extension like plx (meaning PerL eXecutable); see your system's release notes for more information."
dtech
That sounds more like an Apache problem than a Perl problem. It's their mistake and it's not even relevant outside Apache context
maxloh
That should be marked as a breaking change on Apache side IMO. It would be a security nightmare if server code were leaked to public.
weinzierl
It should have been an Apache problem, yes. Not only did it turn out that at least the language negotiation part of content negotiation wasn't the best idea but the way Apache handled it was problematic apart from the pl problem. In the end the Perl community took the issue upon them, so historically I'd say it was a Perl problem (of choice).
gnabgib
Related
The YAML document from hell (566 points, 2023, 353 comments) https://news.ycombinator.com/item?id=34351503
That's a Lot of YAML (429 points, 2023, 478 comments) https://news.ycombinator.com/item?id=37687060
No YAML (Same as above) (152 points, 2021, 149 comments) https://news.ycombinator.com/item?id=29019361
mdaniel
And some light commentary a few days ago: https://news.ycombinator.com/item?id=43648263 - Apr 2025 (51 comments)
hgomersall
IMO the proposed solution of StrictYAML + schema is the right one here and what we use extensively for human readable configs. StrictYAML (linked to in the post) is essentially a string-type-only restriction of YAML, so you impose your type coercion on the parsed data structure.
vander_elst
If you have a schema, why not using directly something like protobufs?
LelouBil
The comment you replied to talks about human readable configs
nnurmanov
Another solution is to change the country name:)
gunalx
Thoug we have renamed amino acidsvi think it was. Because microsoft excel switched the original names to months.
madcaptenor
Genes, not amino acids.
https://www.theverge.com/2020/8/6/21355674/human-genes-renam...
xelxebar
This has been fixed since 2009 with YAML 1.2. The problem is that everyone uses libyaml (_e.g._ PyYAML _etc._) which is stuck on 1.1 for reasons.
The 1.2 spec just treats all scalar types as opaque strings, along with a configurable mechanism[0] for auto-converting non-quoted scalars if you so please.
As such, I really don't quite grok why upstream libraries haven't moved to YAML 1.2. Would love to hear details from anyone with more info.
[0]:https://yaml.org/spec/1.2.2/#chapter-10-recommended-schemas
xigoi
I’m sad that the “fix” was to disallow “no” as a more readable alternative to “false”, rather than to disallow unquoted strings.
mckn1ght
It’s silly to have so many keyword synonyms as specified in that earlier regex. I’m also glad we can’t specify numeric literals as roman numerals. KISS
xigoi
Honestly I’d prefer if “yes” and “no” were the only ways to spell the boolean values. They make sense in pretty much all contexts where booleans are used, whereas “true” and “false” rarely make sense.
xelxebar
The fix is to make conversion user-controllable. If you want to disallow bare scalars except for booleans and numbers or whatever, it's just a little bit of configuration away.
heavenlyblue
Why do you need an alternative spelling of false?
xigoi
`logging: no` clearly says “I do not want logging”. `logging: false` is less explicit – what exactly is false?
pydry
Yeah, you still get the same issue that 3 is an integer, 3.3 is a float and 3.3.3 is a string.
maxloh
Why wasn't that a major version bump, like YAML 2.0?
That sounds like a breaking change that rendered old YAML documents to be parsed differently.
transfire
Absolutely correct! Please correct me if I am wrong, but as far as I know, no one has implemented YAML completely according to spec.
The tag schema used is supposed to be modifiable folks!
And why anyone would still be using 1.1 at this point is just forehead palming foolishness.
raffraffraff
Why not just use quotes all the time for strings?
kergonath
Because that’s annoying. YAML is often written and read by humans. If you want a verbose and more regular way to do it, there is always JSON. But JSON is really annoying to deal with for humans, although it is much better than YAML for several applications.
hnlmorg
You don’t actually need quotes to define a string in YAML. Eg the following syntax
User:
Name: >-
Bob
Phone: >-
01234 56789
Description:>-
This is a
multi line
description
Edit: This stack overflow like provides more details https://stackoverflow.com/questions/3790454/how-do-i-break-a...
kinow
I guess sometikes it is out of your control. I work on a workflow manager where users specify their workflows with YAML. So there's little we can do to prevent them from writing things like no, n, t in a place it could cause some issue like ij the article.
mystifyingpoi
I like that in concept, but 1) literally no one does that (prime example - Kubernetes docs) and 2) it looks much more messy with quotes, when you know that they are unnecessary in 95% of cases.
ashishb
How often do people even encounter this issue? I have been using YAML for 5+ years and have never had it before. Further, I use `yamllint` which points this out as a lint issue "truthy value should be one of [false, true]".
tetha
I don't recall encountering the norway problem in the wild.
Ansible has a pretty common issue with file permissions, because pretty much every numeric representation of a file mode is a valid number in YAML - and most of them are not what you want.
Sure, we can open up a whole 'nother can of worms if we should be programming infrastructure provisioning in YAML, but it's what we have. Chef with Ruby had much more severe issues once people started to abuse it.
Plus, ansible-lint flags that reliably.
jeltz
I have seen it twice but I work in Sweden where we often do things also for the Norwegian market.
hinkley
Fractions are discriminatory when they happen to one individual or group every time or even just the first time.
See also p95 but the same couple of users always see the p99 time, due to some bug.
speedgoose
I have encountered it once, though I live in Norway and worked in IT there for a decade.
Y-bar
Never experienced it for the past 10+ years since the bug was fixed in the spec.
mongol
Has been encountered where I work. A global website with lots of country-specific config.
peanut-walrus
I for one did encounter exactly this problem when configuring a list of countries via ansible for geoip whitelisting.
rat87
I have when getting an openapi yaml file from someone else.
quechimba
We had this issue many years ago when people from Norway couldn't sign up. Took us a while to figure out
dmckeon
Narrow escape for people from Yemen (YE).
magicalhippo
As a Norwegian I'm very curious, where in the pipeline were you using YAML? And why?
I've only seen it used for configuration.
StableAlkyne
I've seen teams use it as a replacement for JSON because it has the perception of being more "modern"
null
tough
usually locale's paths gone wrong
null
TZubiri
I usually think of yaml for internal config files, would never think of yaml for user data.
Don't ask me why though, might have something to do with how it's written like a python file, no user would want to write their data in yaml format.
nurgasemetey
Probably, OP didn't keep user data in YAML, but I think there was config that kept allowed countries to sign up.
duxup
Or were they from Noway ...
Even worse is the all-decimal MAC problem.
Some genius decided that, to make time input convenient, YAML would parse HH:MM:SS as SS + 60×MM + 60×60×HH. So you could enter 1:23:45 and it would give you the correct number of seconds in 1 hour, 23 minutes, and 45 seconds.
They neglected to put a maximum on the number of such sexagesimal places, so if you put, say, six numbers separated by colons like this, it would be parsed as a very large integer.
Imagine my surprise when, while working at a networking company, we had some devices which failed to configure their MAC addresses in YAML! After this YAML config file had been working for literal years! (I believe this was via netplan? It's been like a decade, I don't remember.)
Turns out, if an unquoted MAC address had even a single non-decimal hex digit, it would do what we expected (parse as a string). This is not only by FAR the more common case, but also we had an A in our vendor prefix, so we never ran into this "feature" during initial development.
Then one day we ran out of MAC addresses and got a new vendor prefix. This time it didn't have any letters in it. Hilarity ensued.
(This behavior has thankfully been removed in more recent YAML standards.)