5 ms·

I think that json is mostly a lightweight, human-readable data exchange format for machines to communicate. It's generally not meant to be written by humans.

k_sze 6y ago
There are already better formats if we just want machines to communicate though; e.g. protobuf, msgpack. The whole reason JSON is text-based is to make it human-readable while also enabling data exchange, but the lack of comments works against that goal.
- BiteCode_dev 6y ago
  Not in the browser or in many stalin.
  - oblio 6y ago
    > many stalin. Wasn't there just one Stalin, though?
    - bregma 6y ago
      One was certainly more than enough. Unfortunately, many have tried to pluralize.
    - BiteCode_dev 6y ago
      :D Stdin. New phone, forgot to disable autocorrect.
matsemann 6y ago
But it's used for all kind of config files. And there I would like to comment why stuff is done the way it is.
- blacktriangle 6y ago
  That's not a problem with JSON, that's a problem with people choosing JSON as a configuration file format. I remember seeing some conversation from the JSON authors around comments and specifically not allowing comments into the spec because they did not want people to use them as extension mechanisms, so the whole no comments in JSON thing was very much intentional.
q3k 6y ago
It's not even good for machines to communicate with, considering: - There is no minimum/maximum number/integer value (or sizes) defined in the RFC [1] - you have no guarantee that a number you emit will be readable by all RFC-compliant parsers, so the only safe option is to emit all numbers as strings. There is also no behaviour mandated for parsers that encounter numbers/integers outside of their supported size range, so you can't rely on any fail-safe behaviour. - There is no standardized behaviour for repeated dictionary keys (which are allowed but 'discouraged' per spec), and different implementations will treat them in different ways. This is especially painful when trying to build JSON middleware that does a parse/check/modify/emit of arbitrary data. - Implementations in some languages (eg. Python) are non-RFC compliant by default (`python.dumps` will emit NaN/Inf/-Inf, even though the RFC forbids that), and generally all implementations are similar-but-different-enough to trip you up [2]. All three of these have bitten me in the past when trying to interface with something that spoke JSON, and as such I refuse to design new systems that use JSON as any source of truth. [1] - https://www.rfc-editor.org/rfc/rfc8259.html https://www.rfc-editor.org/rfc/rfc8259.html [2] - http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php

k_sze 6y ago

There are already better formats if we just want machines to communicate though; e.g. protobuf, msgpack. The whole reason JSON is text-based is to make it human-readable while also enabling data exchange, but the lack of comments works against that goal.

BiteCode_dev 6y ago
Not in the browser or in many stalin.
- oblio 6y ago
  > many stalin. Wasn't there just one Stalin, though?
  - bregma 6y ago
    One was certainly more than enough. Unfortunately, many have tried to pluralize.
  - BiteCode_dev 6y ago
    :D Stdin. New phone, forgot to disable autocorrect.

matsemann 6y ago

But it's used for all kind of config files. And there I would like to comment why stuff is done the way it is.

blacktriangle 6y ago
That's not a problem with JSON, that's a problem with people choosing JSON as a configuration file format. I remember seeing some conversation from the JSON authors around comments and specifically not allowing comments into the spec because they did not want people to use them as extension mechanisms, so the whole no comments in JSON thing was very much intentional.

q3k 6y ago

It's not even good for machines to communicate with, considering: - There is no minimum/maximum number/integer value (or sizes) defined in the RFC [1] - you have no guarantee that a number you emit will be readable by all RFC-compliant parsers, so the only safe option is to emit all numbers as strings. There is also no behaviour mandated for parsers that encounter numbers/integers outside of their supported size range, so you can't rely on any fail-safe behaviour. - There is no standardized behaviour for repeated dictionary keys (which are allowed but 'discouraged' per spec), and different implementations will treat them in different ways. This is especially painful when trying to build JSON middleware that does a parse/check/modify/emit of arbitrary data. - Implementations in some languages (eg. Python) are non-RFC compliant by default (`python.dumps` will emit NaN/Inf/-Inf, even though the RFC forbids that), and generally all implementations are similar-but-different-enough to trip you up [2]. All three of these have bitten me in the past when trying to interface with something that spoke JSON, and as such I refuse to design new systems that use JSON as any source of truth. [1] - https://www.rfc-editor.org/rfc/rfc8259.html https://www.rfc-editor.org/rfc/rfc8259.html [2] - http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php