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 appreciate the workaround here, and I’ve tried this in production environments to one degree or another. This usually fails due to another problem: the number of systems that think unexpected JSON keys are an error, is is too damn high.
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.
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 is like the carcinization of programming
That’s not JSON. Note the use of equal signs for the property names. That’s something else.
Equals schmequals.
It could be a
⇨and it would be the same as JSON because it is still a single symbol used as a separator.Now, if it took multiple separators, each giving some specific different meaning, then it would be a something else.
Nah, that’s a Ruby Hash…
schmooby schmash
Carcinisation is the phenomenon of non crabs to evolve crab like characteristics. It is not the process of non crabs becoming true crabs.
In this case the language is trending toward JSON syntax, but it doesn’t have to actually be JSON for carcinisation to be an applicable analogy.
So, you can say, it’s something else? 🤔
Yeah, a joke, if you look up you’ll see it.
Chuck in comments and I’m on board.
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 appreciate the workaround here, and I’ve tried this in production environments to one degree or another. This usually fails due to another problem: the number of systems that think unexpected JSON keys are an error, is is too damn high.
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.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.
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.
Just make JSON5 the new official version and I would be ok
What’s it called when people try to reinvent Lisp for the hundredth time?
carthinazation
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.