JSON is like the carcinization of programming
I love JSON. But I really wish there was a standard that allowed commas with no following items and that there was a syntax for comments.
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"
}
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.
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.
I will die on the hill that XML is a superior config format and people are just afraid of it cause they see the advanced features (that you don't need to use) and think it's too complicated.
Then maybe you should go ahead and write a brutally messed up but somehow ubiquitous scripting language that just somehow has its object instanciations look exactly like xml so those files can be imported right into scripts that then somehow turn into full blown server applications so xml gets the same attention as Json.
I'll call it XMLlamascript
I'm so looking forward to it.
Don't forget to add a "package management" service that at first glance makes importing XMLlamascript modules super easy but at second glance takes down the Internet after you piss off a random maintainer before then turning into a malware distribution engine.
I'd have a much easier time with XML if I could feed it a json schema or something similar so my editor knows the format it should be in.
Like an XSD file?
This looks exactly like what I am looking for. Thank you!
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.
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 likes lua, I don't see the problem.
Never talk to my daughter again
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).
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.
You are not alone, my friend
I love NixOS
TOML v1.1 just looks like HCL.
Just use HCL at that point.
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.
Programmer Humor
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