this post was submitted on 24 Feb 2026
623 points (97.8% liked)
Programmer Humor
30090 readers
2503 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I like this. I also like yaml, I've had very few issues with it and it's nicer to work with than json.
Json's lack of support for trailing commas and comments makes it very annoying for everyday use.
Significant white-space is bullshit and i will die on this hill.
Is there space left on the hill? I want to join you.
I hear there's significant space left
But it's only white space. That's kinda racist.
significant white space to it's classist and racist
Their whole thing is that they don't want to care about it, so if you get to the hill and there's no space, you're SOL.
You are not alone, my friend
Yeah I just want JSON with optionally quoted keys, and comments.
Commas (at least the trailing ones), comments, and nothing else. JSON with type inference seems like an incredibly bad idea...
JSON5 my beloved
Preach!
You're going to indent your code anyway, so why not let the indentation carry meaning?
Because I am not counting white space when I read. Or should we just write machine code/assembler/pick something straight away?
Not sure I'm following the jump from significant whitespace to machine code. How are those related?
Human and machine read differently. If you ignore that (in case with indentation), then why bother with writing human-friendly form of code, when what is going to be really executed is something else?
If anything, that sounds like an argument in favor of significant indentation, not against it. Humans and machines read differently, yes, which is why we tend to add whitespace and indentation to code even for programming languages where it's not significant. We do that expressly because it makes the code more human-friendly, so it's quite the opposite of ignoring their differences.
Because yaml is not a programming language, and debugging why your whatever you're configuring isn't working correctly can be a nightmare. It doesn't tell you you missed an indent on a block, it just assumes it should be there and changes the meaning.
Braces are visually clear.
I think YAML has its fair share of design flaws, but I don't think significant indentation is one of them. It may not be a programming language (which may be debatable), but there are plenty that use syntactic whitespace.
Just the other day I had a list show up as ["a", "b", "c", "d", "e", false, "g", "h", "i"].
The issue was that, without me being overly aware of it, the data was going through a data -> yaml -> data step.
Yes, the data -> yaml filter was broken for not putting general strings in quotes. But IMO the yaml design invites these odd "rare" bugs.
I used to like yaml, but was happy to see Toml taking the niche of human-readable-JSON, but felt the format for nested key-value was a weird choice. However, I've always felt we could just have extended JSON a bit (allow line breaks, comments, if the outermost data type is an object, the curly brackets may be omitted).
Using YAML as an intermediate format between steps of a process is a mistake. I love YAML for configuration but I’d never use it for machine-to-machine anything. If the tool you’re feeding data to requires YAML as input, just give it JSON. All JSON is valid YAML.
Edit: I realize you weren’t the one who made that decision. I’m saying the problem isn’t YAML, the problem is someone using YAML inappropriately.
I completely agree with the general assessment, but then there are always pesky exceptions. In this case the list entered a JavaScript frontend from the yaml header of machine generated content pages for the website framework Hugo. And, of course, after finding the bug, it is clear that things could have been done differently and the issue easily avoided, but I also don't think this was a completely unreasonable design. Since Hugo actually supports JSON headers (not just via the yaml parser, but thanks for that tip!), that was a quick fix. But I'm also somewhat amazed that it was possible for the strung-together fairly standard set of Python libraries (primarily pyyaml) to not get the strings properly quoted.
Like the other person said, that's not really YAML's fault - just whoever decided to use YAML there.
If users aren't intended to interact directly with the data, use JSON.