Hacker News new | ask | show | jobs
by thrwn_frthr_awy 1615 days ago
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.

5 comments

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

I think you are answering the wrong guy, because he agrees with you.
> 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?

No, it's to your comment. One obvious reading of "did you read every relevant spec completely" is that if you didn't read every relevant spec 100% cover to cover then it's your fault that your software had a problem with that spec, and a reasonable person could view that as infeasible (those things get really long). Hence, it's easy to see your comment as victim blaming. (I'm not saying that I do or don't agree with that view, just trying to make sure everyone understands each other.)
Their comment was intended to point out the same thing you're pointing out to the thread root author.
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.

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?

Sorry, I misread the flow of the conversation. If anything my comment made more sense as a reply to the one you replied to, rather than yours.

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!

No problem! I should have quoted that bit at the top of my original comment, as you aren’t the only one who read it that way.
It's not addressing what you said. I don't think what you said is very relevant, as the "read the spec" doesn't add anything to a discussion about whether something is a good idea to use. Length of spec is relevant to that question.
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.

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

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

>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?

> 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?