31–40 of 339 posts
> “While the website went down and we were losing money we chased down a number of loose ends until finally finding the root cause.” And that's why you have a staging environment. Or you debug in production, whatever you prefer.
There exists a couple of mainstream languages that are full of these sorts of interesting behavior, one of them is supposedly cool and productive and the other is supposedly ugly and evil.
YAML had a worse example, once. For the ease of entering time units YAML 1.1 parsed any set of two digits, separated by colons, as a number in sexagesimal (base 60). So 1:11:00 would parse to the integer 4260, as in 1 hour and 11 minutes equals 4260 seconds. Now try plugging MAC addresses into that parser. The most annoying part is that the MAC addresses would only be mis-parsed if there were no hex digits in the str…
slightly related, on my microwave 99 > 100, even 61 > 100
Earlier quoted context omitted.
They all have their downsides. JSON: - no comments, unless you fake them with fake properties, unless your configuration has a schema that doesn't allow extra fake properties - no trailing commas; makes editing more annoying - no raw strings YAML: - the automatic type coercion - the many ways to encode strings ( https://yaml-multiline.info/ ) - the roulette wheel of whether this particular parser is anal about two-sp…
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.
This 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_...
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.
YAML seems like a really neat idea, but over time, I have I have come to regard it as being too complicated for me to use for configuration. My personal favorite is TOML, but I would even prefer plain JSON over YAML The last thing I want at 2 AM when trying to look figure out if an outage is due to a configuration change is having to think if each line of my configuration is doing the thing I want. YAML prizes making…
They all have their downsides. JSON: - no comments, unless you fake them with fake properties, unless your configuration has a schema that doesn't allow extra fake properties - no trailing commas; makes editing more annoying - no raw strings YAML: - the automatic type coercion - the many ways to encode strings ( https://yaml-multiline.info/ ) - the roulette wheel of whether this particular parser is anal about two-sp…
You wouldn't serialize data structures to jsonnet though, you'd just generate JSON.
Earlier quoted context omitted.
They all have their downsides. JSON: - no comments, unless you fake them with fake properties, unless your configuration has a schema that doesn't allow extra fake properties - no trailing commas; makes editing more annoying - no raw strings YAML: - the automatic type coercion - the many ways to encode strings ( https://yaml-multiline.info/ ) - the roulette wheel of whether this particular parser is anal about two-sp…
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.
This 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…