I love NixOS
this post was submitted on 24 Feb 2026
559 points (98.1% liked)
Programmer Humor
30013 readers
2058 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
As someone who likes lua, I don't see the problem.
The very minor and nitpicky problem is that if you want JSON just use JSON. there's still a place in the world for human readable/ editable configs that don't require linters to be run on them after. (Current TOML is fine, I like it).
JSON is like the carcinization of programming
Chuck in comments and I'm on board.
_comment: "this is a comment"
They were chucked out because, according to the guy who defined it, people started using them for parsing directives, which hurt interoperability because now you needed to be sure that the parser would both read the comments and interpret them correctly. Suddenly, those comments might make otherwise identical files parse differently. If the whole point is that it's reliable and machine-readable, keeping it to the minimal set of features and not extending it any way whatsoever is a good way to ensure compatibility.
What you can do is define some property for comments. It's not standardised, but you could do stuff like
{
"//": "This is a common marker for comments",
"#": "I've never seen that as a property name, so it might be safe?",
"_comment": "Property names with underscore for technical fields seem common enough as well, and it's semantically explicit about its purpose"
}
And also, JSON was intended as a data serialisation format, and it's not like computers actually get value from the comments, they're just wasted space.
People went on to use JSON for human readable configuration files, and instantly wanted to add comments, rather than reconsider their choice because the truth is that JSON isn't a good configuration format.
JSON was intended as a data serialisation format
Why then use a inefficient text based format instead of a much more efficient and easy to parse binary format?
Just use DER encoded ASN.1 like a normal person.
People went on to use JSON for human readable configuration files
Speaking from my own experience, "I could also use this for..." seems to be a ubiquitous programmer affliction. Single-purpose tools that are great at their thing tend to be short-lived unicorns until someone starts sticking other parts onto them for additional functionalities, taking off the horn because it's in the way for some thing or other, and somehow we end up with yet another multi-function-tool that does a lot of things poorly.
If we’re adding comments to json, can we add canonical support for trailing commas?
load more comments
(4 replies)
load more comments
(2 replies)
load more comments
(20 replies)
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.
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).
Significant white-space is bullshit and i will die on this hill.
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.
Is there space left on the hill? I want to join you.
I hear there's significant space left
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.
But it's only white space. That's kinda racist.
significant white space to it's classist and racist
load more comments
(3 replies)
Time to read this if you haven't already
https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
The json spec is not versioned. There were two changes to it in 2005 (the removal of comments
See, this is why we can't have nice things.
load more comments
(4 replies)
If yaml didn’t have anchors and 8 different white space formats, it’d be a great replacement for this kind of thing.
But yaml is a mess, and you’d think you could parse it easily, but you can’t.
load more comments
(20 replies)
If this is where the toml train ends I will be happy with it. If they do a yaml, I will be very upset.
view more: next ›