Jason really should check his MQTT Server
this post was submitted on 24 Feb 2026
622 points (97.7% liked)
Programmer Humor
30160 readers
1342 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
JSON is like the carcinization of programming
Chuck in comments and I'm on board.
If we’re adding comments to json, can we add canonical support for trailing commas?
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"
}
I'm not a real programmer but I was wondering wtf you're on about because I don't think I've ever worked with a json file in a system that didn't use // for comments lmfao
load more comments
(3 replies)
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.
load more comments
(2 replies)
load more comments
(2 replies)
Well...
It's name-value pairs, with groups denoted by balanced brackets. It's close to as good as you can get for one kind of data serialization.
What is impressive is how many problems people manage to fit in something so small.
What's it called when people try to reinvent Lisp for the hundredth time?
load more comments
(3 replies)
load more comments
(16 replies)
orange = {
you = "glad",
I = {
didn\'t = {
say = "banana"
}
}
}
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.
As someone who works with YAML regularly:
Fuck YAML.
Nah, yaml isn't great by virtue of itself but with what it competes with. I far, far prefer it to any other BS. Json is garbage for human creation and obviously toml due to above. XML... Obviously just for machines.
Again, only good because of its competition.
load more comments
(1 replies)
As someone who runs Home Assistant:
Fuck YAML.
I want to like yaml, I really do, but why are there so many different ways of specifying the same thing?
load more comments
(1 replies)
I have a fundamental disdain for formats with restrictive white space definitions (I’m looking too at you Python)
I’ve never had this issue with Python, but makefile has given me plenty of whitespace issues.
load more comments
(3 replies)
load more comments
(5 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.
I can kind of understand it after having to work with an XML file where users encoded data into comments for no good reason. But yeah, it does make JSON awkward for lots of potential use-cases.
Anything can be abused. That’s not a legitimate reason to take away perfectly reasonable features. Looking at you, Java (unsigned integers).
load more comments
(2 replies)
load more comments
(6 replies)
As if I didn't hate the format enough before
load more comments
(4 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.
Significant white-space is bullshit and i will die on this hill.
load more comments
(12 replies)
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.
load more comments
(2 replies)
load more comments
(5 replies)
load more comments
(4 replies)
TOML's design is based on the idea that INI was a good format. This was always going to cause problems, as INI was never good, and never a format. In reality, it was hundreds of different formats people decided to use the same file extension for, all with their own incompatible quirks and rarely any ability to identify which variant you were using and therefore which quirks would need to be worked around.
The changes in the third panel were inevitable, as people have data with nested structure that they're going to want to represent, and without significant whitespace, TOML was always going to need some kind of character to delimit nesting.
Well, Wikipedia does say:
The [TOML] project standardizes the implementation of the ubiquitous INI file format (which it has largely supplanted[citation needed]), removing ambiguity from its interpretation.
Nix is the next step in that evolution. It's basically just JSON that can generate itself !
Sounds like Nix is a pathway to many abilities I consider to be unnatural.
Yeah, it really is. A plaintext document that generates an entire OS?
load more comments
(1 replies)
It’s basically just JSON that can generate itself !
You have inspired me.
I will make JSON with meta-programming
I will call it DyJSON, i.e. "Dynamic JSON" but pronounced "Die, Jason!"
It is JSON with meta-programming and the ability to call C functions from libraries
Example:
# This is a line comment
# Put your function definitions up here
(concat str_a str_b: "concat" "my-lib.so") # Import a function through a C ABI
(make-person first_name last_name email -> { # Define our own generative func
"name": (concat (concat $first_name " ") $last_name),
"email": $email
})
# And then the JSON part which uses them
[
(make-person "Jenny" "Craig" "jenn.craig.420@hotmail.com"),
(make-person "Parson" "Brown" null)
]
As you can see, it is also a LISP to some degree
Is there a need for this? A purpose? No. But some things simply should exist
Thank you for helping bring this language into existence
load more comments
(1 replies)
load more comments
(3 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.
load more comments
(1 replies)
No, sir. That's an inline table, sir. That is clearly totally different, sir!