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.
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.
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
No biggie, I just named an example. Even “real” programmers, whatever definition you want to use for that, don’t know all languages.
But yes, many languages do use // as comments and particularly the Javascript environment it originally stems from does. Python (#) and SQL (--) are the only examples I interact with frequently enough to know off the top of my head (but SQL still recognises /* ... */ for delimited comments). XML/HTML also has <!-- --> for comments, but that’s not so much a programming and more of a description language.
Chuck in comments and I’m on board.
If we’re adding comments to json, can we add canonical support for trailing commas?
Found the python guy!
Oh, a trailing comma? That’s a tuple.
Yeah when the call_func((a,)) is the way to go it is a newbie pain for sure. Remember banging my head on that one.
I’ve spent hours on that, and debugging missing commas between string literals. Even on separate lines you’re not safe from implicit concatenation.
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.
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.
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.
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
Python, for example
I did say “I’m not a real programmer” heh 😮💨 I just thought // was standard for comments across all json files
No biggie, I just named an example. Even “real” programmers, whatever definition you want to use for that, don’t know all languages.
But yes, many languages do use // as comments and particularly the Javascript environment it originally stems from does. Python (
#) and SQL (--) are the only examples I interact with frequently enough to know off the top of my head (but SQL still recognises/* ... */for delimited comments). XML/HTML also has<!-- -->for comments, but that’s not so much a programming and more of a description language.Just make JSON5 the new official version and I would be ok
That seems quite good, not overdoing it too.
_comment: “this is a comment”
Nah that sucks in so many ways thank you 😊