[thrwn_frthr_awy]

Did you read the entire YAML spec before using it (https://yaml.org/spec/1.2-old/spec.html_? And all other specs? And docs for all your dependencies? What about docs for system services on all your servers?

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.

[PragmaticPulp]

> Did you read the entire YAML spec before using it (https://yaml.org/spec/1.2-old/spec.html_?

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.

[rat9988]

I think you are answering the wrong guy, because he agrees with you.

[thrwn_frthr_awy]

> This feels like an attempt at victim blaming

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?

[quietbritishjim]

Your tone suggests you think it's obviously infeasible to read the whole YAML speed before using it. But it is possible to read the whole JSON spec [1]. It takes less than a minute.

[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.

[thrwn_frthr_awy]

My comment was to point out how ridiculous the parents comment is in response to the article.

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?

[andi999]

Thanks, I havent seen that before. It took me 10 minutes to go through and it is very clear (took a moment to realize whitespace also alllows no character).

A couple of years ago I looked at tutorials and found it very confusing, but the spec is just great.

[ExtraE]

While you’re right it’s a shorter spec (setting aside if you’re right about your broader point) this [0] is a more reasonable spec. Even JSON with its microscopic spec has implementation details, inconsistencies, and errata. Is this why we can’t have nice things?

[0] - https://datatracker.ietf.org/doc/html/rfc7159

[isatty]

I’m not sure what this comment is trying to say. I’ve been programming for a while and I know plenty of talented, amazing engineers. Nobody reads the whole spec top to bottom for like, anything.

[smokey_circles]

> edge-cases

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

[LudwigNagasena]

>Did you read the entire YAML spec before using 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?

[thrwn_frthr_awy]

> No, not the entire spec, but I glanced through the wiki page and a few tutorials to understand it.

Then how are you protecting yourself from “innocuous bugs” you mention without reading all of the spec?