5 ms·

For a format designed to be human readable, JSON not supporting comments is a major let down. And not supporting trailing comma.

speedgoose 4y ago
You have the superset JSON5 https://json5.org/ https://json5.org/ but it’s quite rare compared to JSON.
singularity2001 4y ago
Adding comments to json is the one breaking change the world needs. As a parser if you stumble over a comment it's your fault! nothing in the world could stop you from just sanely ignoring comments.
- alpaca128 4y ago
  JSON5 exists and allows both comments and trailing commas. It's basically like defining objects in plain JavaScript syntax.
  - jgalt212 4y ago
    what's the difference between JSON5 and the config language that vs code uses ,JSON + comments (as best I can tell).
    - nicoburns 4y ago
      JSON5 also allows extra things like single-quoting strings and multiline strings. VS Code uses JSONC which is strictly trailing commas and comments on top of JSON
grey-area 4y ago
What’s wrong with using a ‘comment’ key? I’d say not supporting large ints is worse. https://stackoverflow.com/questions/209869/what-is-the-accepted-way-to-send-64-bit-values-over-json https://stackoverflow.com/questions/209869/what-is-the-accep...
- solarkraft 4y ago
  It's pretty inconvenient and ends up in the data, rather than being external to it.
- noctune 4y ago
  JSON supports numbers of arbitrary and just fine. It's just many reader/writers of JSON does not, and those are so ubiquitous that it's often not practical to use.
  - grey-area 4y ago
    Unfortunately in practice you can’t rely on large numbers being passed through correctly because of this, unless you control both ends and don’t use js.
  - olejorgenb 4y ago
    AFAIK, json does not support NaN and Inf which can be a pain sometimes
- Uvix 4y ago
  A comment key works for commenting JSON objects, but not for commenting specific keys on an object or values in an array.
  - grey-area 4y ago
    I don’t find that a huge limitation personally. I don’t think data formats should allow comments on values, that is what docs are for.
moring 4y ago
Counterpoint: In practically every language that supports comments, these "comments" are now used for language extensions (IDE folding markers, eslint-ignore, FPGA synthesis hints, ...) Please don't do that to JSON.
- IshKebab 4y ago
  What exactly is wrong with that? Comment hints like that are quite common and with a few exceptions (synthesis hints) they are all optional hints that have no effect on the main interpretation of the code. IDE folding markers aren't going to hurt anyone. Chrome doesn't care about lint waivers. Etc.
  - mst 4y ago
    Things like comments being used to provide optimiser hints in SQL queries are the bane of people writing parsers or anything that depends on them. I think folding/lint/etc. markers are poor examples here, because they're basically annotations for other tools which seems entirely fine. However comments that affect the behaviour of the code itself are really much less fun to deal with. Worrying that JSON implementations would end up acquiring the latter is pretty fair given our track record as a species.
    - IshKebab 4y ago
      > comments that affect the behaviour of the code itself... I agree, but those are extremely rare in my experience. SQL optimiser hints and HDL synthesis hints only affect performance. What examples are there of comments affecting actual behaviour such that tools must parse them for the code to even run? I can't think of any.
      - mst 4y ago
        I do see what you're getting at but in the SQL case an unhinted statement can potentially produce such a terrible plan it invariably times out and triggers a 500 from the service making the query. This sort of thing somewhat blurs the boundaries between affecting performance and affecting behaviour. I'm not claiming that there's an obviously right answer here, only that there can be more questions about whether something is a good idea on net than people always consider. Note: It would not surprise me to find that the actual motivation for leaving comments out of JSON went something like: 1) We can't have line comments because we don't want to be newline sensitive that way 2) If we do /* ... */ style comments people -will- write incompatible parsers for them no matter how carefully we specify them 3) Argh but I wasn't there at the time, so the question will have to remain open.
Null-Set 4y ago
I know the maintainer of the JSON spec, his main job is to make sure no one changes it to add these.
throw0101c 4y ago
> For a format designed to be human readable, JSON not supporting comments is a major let down. Comments were an explicit anti-feature. Douglas Crockford in 2012: > I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. * https://web.archive.org/web/20120507104813/https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr https://web.archive.org/web/20120507104813/https://plus.goog... * https://news.ycombinator.com/item?id=3912149 https://news.ycombinator.com/item?id=3912149 (discussion at the time) And JSON primary purpose was to be a data interchange format; the fact that is human-readable text is a nice bonus.
- afiori 4y ago
  A choice can be a good choice and still lead to worse results. As things are now trailing commas and comments would make JSON a better format, whether they were a good compromise at the time is not really the point.

speedgoose 4y ago

You have the superset JSON5 https://json5.org/ https://json5.org/ but it’s quite rare compared to JSON.

singularity2001 4y ago

Adding comments to json is the one breaking change the world needs. As a parser if you stumble over a comment it's your fault! nothing in the world could stop you from just sanely ignoring comments.

alpaca128 4y ago
JSON5 exists and allows both comments and trailing commas. It's basically like defining objects in plain JavaScript syntax.
- jgalt212 4y ago
  what's the difference between JSON5 and the config language that vs code uses ,JSON + comments (as best I can tell).
  - nicoburns 4y ago
    JSON5 also allows extra things like single-quoting strings and multiline strings. VS Code uses JSONC which is strictly trailing commas and comments on top of JSON

grey-area 4y ago

What’s wrong with using a ‘comment’ key? I’d say not supporting large ints is worse. https://stackoverflow.com/questions/209869/what-is-the-accepted-way-to-send-64-bit-values-over-json https://stackoverflow.com/questions/209869/what-is-the-accep...

solarkraft 4y ago
It's pretty inconvenient and ends up in the data, rather than being external to it.
noctune 4y ago
JSON supports numbers of arbitrary and just fine. It's just many reader/writers of JSON does not, and those are so ubiquitous that it's often not practical to use.
- grey-area 4y ago
  Unfortunately in practice you can’t rely on large numbers being passed through correctly because of this, unless you control both ends and don’t use js.
- olejorgenb 4y ago
  AFAIK, json does not support NaN and Inf which can be a pain sometimes
Uvix 4y ago
A comment key works for commenting JSON objects, but not for commenting specific keys on an object or values in an array.
- grey-area 4y ago
  I don’t find that a huge limitation personally. I don’t think data formats should allow comments on values, that is what docs are for.

moring 4y ago

Counterpoint: In practically every language that supports comments, these "comments" are now used for language extensions (IDE folding markers, eslint-ignore, FPGA synthesis hints, ...) Please don't do that to JSON.

IshKebab 4y ago
What exactly is wrong with that? Comment hints like that are quite common and with a few exceptions (synthesis hints) they are all optional hints that have no effect on the main interpretation of the code. IDE folding markers aren't going to hurt anyone. Chrome doesn't care about lint waivers. Etc.
- mst 4y ago
  Things like comments being used to provide optimiser hints in SQL queries are the bane of people writing parsers or anything that depends on them. I think folding/lint/etc. markers are poor examples here, because they're basically annotations for other tools which seems entirely fine. However comments that affect the behaviour of the code itself are really much less fun to deal with. Worrying that JSON implementations would end up acquiring the latter is pretty fair given our track record as a species.
  - IshKebab 4y ago
    > comments that affect the behaviour of the code itself... I agree, but those are extremely rare in my experience. SQL optimiser hints and HDL synthesis hints only affect performance. What examples are there of comments affecting actual behaviour such that tools must parse them for the code to even run? I can't think of any.
    - mst 4y ago
      I do see what you're getting at but in the SQL case an unhinted statement can potentially produce such a terrible plan it invariably times out and triggers a 500 from the service making the query. This sort of thing somewhat blurs the boundaries between affecting performance and affecting behaviour. I'm not claiming that there's an obviously right answer here, only that there can be more questions about whether something is a good idea on net than people always consider. Note: It would not surprise me to find that the actual motivation for leaving comments out of JSON went something like: 1) We can't have line comments because we don't want to be newline sensitive that way 2) If we do /* ... */ style comments people -will- write incompatible parsers for them no matter how carefully we specify them 3) Argh but I wasn't there at the time, so the question will have to remain open.

Null-Set 4y ago

I know the maintainer of the JSON spec, his main job is to make sure no one changes it to add these.

throw0101c 4y ago

> For a format designed to be human readable, JSON not supporting comments is a major let down. Comments were an explicit anti-feature. Douglas Crockford in 2012: > I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. * https://web.archive.org/web/20120507104813/https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr https://web.archive.org/web/20120507104813/https://plus.goog... * https://news.ycombinator.com/item?id=3912149 https://news.ycombinator.com/item?id=3912149 (discussion at the time) And JSON primary purpose was to be a data interchange format; the fact that is human-readable text is a nice bonus.

afiori 4y ago
A choice can be a good choice and still lead to worse results. As things are now trailing commas and comments would make JSON a better format, whether they were a good compromise at the time is not really the point.