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.
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?
[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.
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!
A couple of years ago I looked at tutorials and found it very confusing, but the spec is just great.
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
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?