Always read documentation or you will get burned by something completely innocuous. For example, that’s how you get Norway missing in your config file with YAML:
NI: Nicaragua
NL: Netherlands
NO: Norway
Software/specs/formats have edge-cases. Theses exists usually because of a tradeoff in usability. That's why there is YAML, JSON, TOML, etc. Choose the one that best fits your use-case and the strictness you need.
This feels like an attempt at victim blaming. If you have to read an entire spec from top to bottom to avoid a pitfall in a relatively common operation, maybe something is wrong.
FWIW, I couldn't even find the relevant section in that spec from a quick glance. I probably would have to read a significant portion of that spec just to figure out where it went wrong.
I don't think I understand what this means in context of my comment. Are you referring to the parent of my comment?
Someone wrote an article about an interesting thing they discovered about a well-known spec and OP's response is "Are people not even reading about what they are using?" Did the author of the article do something wrong?
No, not the entire spec, but I glanced through the wiki page and a few tutorials to understand it.
>Choose the one that best fits your use-case and the strictness you need.
Well, how can one choose what fits best if they don't even research the topic?
Then how are you protecting yourself from “innocuous bugs” you mention without reading all of the spec?
[1] https://www.json.org/json-en.html
Saying that all formats have edge cases as an excuse for YAML's glaring faults is, frankly, a cop out. Like if a bridge collapses when a leaf lands on it and saying, well, all bridges have some maximum load. Yes, but in this case it's so bad it's just not useful for anything.
A couple of years ago I looked at tutorials and found it very confusing, but the spec is just great.
What does the length of the JSON spec have to do with my comment? The parent comment says if you don’t read all your docs you will be bit by an innocuous bug. You linked to a short spec, but that doesn’t mean anything in this context.
> Like if a bridge collapses when a leaf lands on it and saying, well, all bridges have some maximum load.
Is that what you got from reading my comment or the article? Is that what yaml is like?
More specifically, I missed the first line of their comment: "Are people not even reading about what they are using?" If you miss off that line, then it sounds (to me) that they're arguing YAML is a terrible format. With that line, it turns out they think it's reasonable, so long as you read the (huge) spec first. Madness!
Those are forgivable. I watched a team get burned by doing software HMAC and it turns out the underlying native function in the kernel is not thread safe. Would have caught me too.
JSON being a subset of YAML is a core feature. It was to help with adoption.
There's a difference in not reading all pages of every document and not reading anything at all. Not even a well researched blog post.
If this individual is a junior, then awesome, they learned a lot of valuable ideas and solutions.
If they're a senior, yikes. Don't use technology you can't explain to the junior discovering core features and writing blog posts about it
(This issue was recognised and since yaml 1.2 (2009) the spec says "no" is a string, packages like https://yaml.readthedocs.io/ have migrated a while ago)
Not breaking backwards compatibility in a minor version bump of a data format was absolutely common sense in 2009.
1 : 1,0
2: 01
3: 1.0
4: 1O
5: 0b1
6: 0x1
7: 0i1
8: hey,
8.0: oh,
version: [3.1, "3.1", 3.10, "3.10"]
{
"1": "1,0",
"2": 1,
"3": 1.0,
"4": "1O",
"5": 1,
"6": 1,
"7": "0i1",
"8": "oh,",
"version": [
3.1,
"3.1",
3.1,
"3.10"
]
}
1. Significant whitespace in a data storage file doesn't scale. Yes, eventually someone wants to dump a giant graph of data and the library breaks.
2. Intermixed context on quoteless strings. Intermixing code and data doesn't work reliably. Every where I see it tried I see it break. If you don't want quotes on your strings, then you have to put something on your keywords. A simple @no would have stopped this and other situations.
As an aside, I find it stupid to have multiple names for true, false, and null.
If config file is autogenerated then it's a different matter.
What is this strange concept you bring up? Googling saved me an entire day of reading dry documents. I may not know how the code works, but I go around telling everyone how easy coding is because of copy+paste.