Related xkcd
The Norway Problem
41–50 of 339 posts
Re: The Norway Problem
#42Earlier quoted context omitted.
This makes me sad. It's 2021 and we still haven't figure out how to serialize configuration in a format that is easy-to-edit and predictable.
We had such: XML. With proper editor support it is easy. I guess it needs rediscovery /s ;)
I used XML and didn't like it:
- A proper editor was never around.
- Closing tags were verbose.
- Attributes vs tags was confusing.
- It didn't map "naturally" to common data types, like lists, maps, integers, float, etc.
Re: The Norway Problem
#43This is why i love JSON. It's only string, number, boolean, arrays, objects/dictionaries, unless you write custom serializer and deserializers..
Re: The Norway Problem
#44This is part of more general problem, they had to rename a gene to stop excel auto-completing it into a date. https://www.theverge.com/2020/8/6/21355674/human-genes-renam... Edit: Apparently Excel has its own Norway Problem ... https://answers.microsoft.com/en-us/msoffice/forum/msoffice_...
> This is part of more general problem The more general problem basically being sentinel values (which these sorts of inferences can be treated as) in stringly-typed contexts: if everything is a string and you match some of those for special consideration, you will eventually match them in a context where that's wholly incorrect, and break something.
That’s a shrewd observation. Static types help with this somewhat. E.g. in Inflex, if I import some CSV and the string “00.10” as 0.1, then later when you try to do work on it like
x == “00.10”
You’ll get a type error that x is a decimal and the string literal is a string. So then you know you have to reimport it in the right way. So the type system told you that an assumption was violated.
This won’t always happen, though. E.g. sort by this field will happily do a decimal sort instead of the string 00.10.
The best approach is to ask the user at import time “here is my guess, feel free to correct me”. Excel/Inflex have this opportunity, but YAML doesn’t.
That is, aside from explicit schemas. Mostly, we don’t have a schema.
Re: The Norway Problem
#45I will never understand why YAML didn't just require quoted strings. Did the creator not anticipate how many problems the ambiguity would cause?
Never's a strong word, seems quite easy to understand why to me. You've got ease of use reasons, historical reasons like the mis-guided Robustness principle, etc.
And these sort of things happen time and time again.
And although officially JSON requires quoted strings, almost none of the parsers actually enforce that, and so you will find a huge amount of JSON out there that is not actually compliant with the official spec.
Just like browsers have huge hacks in them to handle misformed HTML.
Re: The Norway Problem
#46[deleted]
Re: The Norway Problem
#47> The most tragic aspect of this bug, howevere, is that it is intended behavior according to the YAML 2.0 specification.
This is one of those great ideas that sadly one needs experience to realize are really bad ideas. Every new generation of programmers has to relearn it.
Other bad ideas that resurface constantly:
1. implicit declaration of variables
2. don't really need a ; as a statement terminator
3. assert should not abort because one can recover from assert failures
Re: The Norway Problem
#48This is part of more general problem, they had to rename a gene to stop excel auto-completing it into a date. https://www.theverge.com/2020/8/6/21355674/human-genes-renam... Edit: Apparently Excel has its own Norway Problem ... https://answers.microsoft.com/en-us/msoffice/forum/msoffice_...
Good language design involves deliberately adding redundancy which acts like a parity bit in that errors are more likely to be detected.
Re: The Norway Problem
#49Earlier quoted context omitted.
We had such: XML. With proper editor support it is easy. I guess it needs rediscovery /s ;)
I used XML and didn't like it: - A proper editor was never around. - Closing tags were verbose. - Attributes vs tags was confusing. - It didn't map "naturally" to common data types, like lists, maps, integers, float, etc.
Don't forgot about namespaces, another fiddly bit of XML that caused all sorts of problems and headaches.
Re: The Norway Problem
#50This is exactly why configuration/serialization formats should make as few assumptions about value types as possible. Once parsing's done, everything should be a string (or possibly a symbol/atom, if the program ingesting such a file supports those), and it should be up to the application to convert values to the types it expects. This is Tcl's approach, and it's about as sensible as it gets. ...which is why it pains…
> Once parsing's done, everything should be a string
Or give a schema to the parser, defining what type is expected in each field.