51–60 of 339 posts
In the first model entering
GB 9.3
gets you a string and a number.
But the second gets you two strings?
Both are wrong in my opinion.
"GB" 9.3
is the correct approach
Explicit beats implicit every time.
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.
* Text AND binary so that humans can edit easily, and machines can transmit energy and bandwidth efficiently.
* Carefully designed spec to avoid ambiguities (and their security implications).
* Strong type support so you're not using all kinds of incompatible hacks to serialize your data.
* Versioned, because there's no such thing as the perfect format.
* Also, the website is 32k bytes ;-)
What I am most baffled by with Yaml is the fact that it’s a superset of JSON. Whenever an input accepts YAML you can actually pass in JSON there and it’ll be valid It really surprised me when I found out and I use JSON Whenever possible since then since it’s much stricter https://en.m.wikipedia.org/wiki/JSON#YAML
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_...
OOH, this is a a typically human problem. We have a system. It's partly designed, partly evolved^. It's true enough to serve well in the contexts we use it in on most days. There are bugs in places (like norway, lol) that we didn't think of initially, and haven't encountered often enough to evolve around.
In code, we call it bugs. In bureaucracy, we just call it bureaucracy. Agency A needs institution B's document X, in a way that has bugs.
Obviously, it's also a typical machine problem. @hitchdev wants to tell pyyaml that Norway exists, and pyyaml doesn't understand. A user wants to enter "MARCH1" as text (or the name of a gene), and excel doesn't understand.
Even the most rigid bureaucracy is made of people and has fairly advanced comprehension ability though. If Agency A, institution B or document X are so rigid that "NO" or "MARCH1" break them... it probably means that there's a machine bug behind the human one.
Meanwhile... a human reading this blog (even if they don't program) can understand just fine from context and assumptions of intent.
IDK... maybe I'm losing my edge, but natural language programming is starting to seem like a possibility to me.
^I feel like we need a new word for these: versioned, maybe?
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.
and yet I don't see anyone complain about bash which is arguably far worse than those 2. When things get hard on bash, you will start to see python scripts on CI and whole thing is complete unreadable mess
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…
Only when you "unmarshal" to an untyped data structure and then make assumptions about the type. I've used yaml with a go application, and it can't interpret NO as a bool when the field is a string.
Or… just quote your strings.
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…
There was a list of AWS Account IDs that parsed just fine until someone added one that started with a 0 and had no numbers greater than 7 in it, after which our parser started spitting out decidedly different values than we were expecting. Fixing it was easy, but figuring out what in the heck was going on took some digging.
> 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 shoul…
This is so true. I really like Julia and I know that explicitly declaring variables would be detrimental to adoption but I prefer it to the alternative, which is this: https://docs.julialang.org/en/v1/manual/variables-and-scopin...