6 ms·

And comments. Not being able to put comments in JSON files is beyond stupid.

jrockway 7y ago
JSON is a binary computer-to-computer interchange format. No computer-to-computer interchange format has comments. The problem with JSON is that it's just human-readable enough that people think it's a config file format. It's not.
- knodi123 7y ago
  What are the material differences between a config file format, and a machine-to-machine only format?
  - inetknght 7y ago
    Well, for one: most config file formats specifically include a method for the user to add bytes to the data which won't be parsed or interpreted. In JSON... you might try adding a {"comment": "this is a bad way to comment"} object or key/value and hope you don't collide with an object's dedicated comment field, and also don't cause the parser to raise an error for having a field which it didn't expect.
  - korijn 7y ago
    The key difference is the target audience. The format's "UX", so to speak, is optimized for the target audience (machine or human). @jrockway makes an excellent point.
    - mark-r 7y ago
      Why must those be mutually exclusive? There's value in being understandable by both.
      - nitrogen 7y ago
        Having comments in a "wire format" provides a means for the spec to become meaningless as random applications start using comments to convey information (or exfiltrate data) that other applications cannot parse correctly.
        mark-r 7y ago
        There should be a special place in hell reserved for people who use comments to convey machine readable information. The whole point of a comment is to provide something that has no semantic meaning.
  - haggy 7y ago
    Config files are typically a 'load once, read many" pattern. Machine to machine communication protocols can be VERY high rate and over the network so they need to be highly efficient both in memory footprint and serialization overhead.
    - iainmerrick 7y ago
      So... JSON isn’t great as a machine to machine protocol, then? So I guess it must be a config format after all!
  - robotnikman 7y ago
    I would think being able to have comments is a big one, so you at lease have an idea of what changes what in a config file.
- mark-r 7y ago
  Any format that can be edited with a text editor and retain proper formatting should be able to have embedded comments. No reason not to, and it can come in handy sometimes.
  - ghayes 7y ago
    The argument, originally, I believe was that comments might be hacked to “extend” JSON with various additions (e.g. dates via an end of line marker). Comments were excluded to keep the format stable, which, FWIW, has worked.
    - ric2b 7y ago
      That's a bad argument, since you can still do that with "magic" fields or metadata fields.
      - deleted 7y ago
        [deleted]
- btilly 7y ago
  No computer-to-computer interchange format has comments. I call BS. As a counterexample search for the word "comment" in https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. Or are you saying that http is not a computer-to-computer interchange format?
  - jrockway 7y ago
    You call BS because the HTTP/1.1 standard calls pieces of text that contain the name of the software at the other end of the connection "comments"? (To those that didn't read the spec, it uses the word comment to refer to the values in the User-Agent, Server, and Via headers.) It turns out these "comments" were a disaster and user agents are moving away from even providing them. You put "firefox" in the user-agent header, and web servers would read the comment and send you "your browser doesn't work" instead of the actual document. That did not make for a very compatible web... turns out comments in machine-to-machine communication are a bad idea.
    - deleted 7y ago
      [deleted]
    - btilly 7y ago
      Yes, comments tend to be turned over time into hints, directives, etc, etc, etc. But that doesn't change the fact that people put comments into machine protocols. For another example, lots of machine to machine protocols specify XML. Such as SOAP. They therefore all support comments. In accord to the general trend, eventually they get abused into having a semantic meaning. For example https://support.ptc.com/help/windchill/wc111_hc/whc_en/index.html#page/Windchill_Help_Center/IEUG_SOAPWritingTasks_IEUG_SOAPComments.html https://support.ptc.com/help/windchill/wc111_hc/whc_en/index... shows how one system uses comments in SOAP to create documentation and a WSDL that lets interfaces to your code to be automatically generated. And so comments eventually become executable. But that doesn't change the fact that comments can exist in machine to machine formats.
      - Mikhail_Edoshin 7y ago
- gameswithgo 7y ago
  Either it is a terrible format because it is such a massively wasteful (in terms of payload size and cpu overhead to serialize and deserialize) computer to computer interchange format, or it is terrible because it doesn't have comments.
  - jrockway 7y ago
    Yeah, it's not a very good computer-to-computer format. No bytes type. No integer type. No Any->Any maps. Being bad at something doesn't automatically make you good at something else, and JSON is no exception. It's bad at everything except being popular. You have to look at JSON in a historical context to understand it. It exists so that someone could get some data into their Javascript program with "eval". It was then standardized so that you didn't need a full Javascript engine to understand it, because Python and Perl and Ruby didn't have one, and it turned out that evalling random data from the Internet was a security disaster. Does that make it a good human-readable config file? Nope. Does that make it a good interface definition language? Nope. It exists because it got popular early, and now we're stuck with it. Now it's too late to apply band-aids to make it a human-readable config language or a good computer-to-computer interchange format, because you will always have old parsers around and people will naturally want to target those. Trust me, 99% of developers will moan when you tell them that they have to use GRPC+Protos to access your API. They will be equally mad about your JSON extension that has comments and integers in it, because the dialect of Brainfuck they use for all their projects doesn't have a library that supports those extensions and their editor can't syntax-highlight it or autoformat it. I would like to give you a solution to this problem, but there isn't one. JSON "won", but it's bad at everything except being well-understood. That seems to be all that people really care about.
- metaloha 7y ago
  JSON isn't binary, it's text-based and human-readable by design (similar to YAML in that sense). JSONB is a binary variant, though, potentially more suitable for machine-to-machine communication and stores more efficiently in databases as a BLOB.
- iainmerrick 7y ago
  The problem with JSON is that it's just human-readable enough that people think it's a config file format. It's not. That attitude is misguided. Many people do in fact use JSON as a config file format, so it is a config file format. Real world usage outweighs prescriptions about what is and isn’t correct. Looking at the first standardized JSON spec, it’s not particularly prescriptive about usage, simply saying: JSON is syntax of braces, brackets, colons, and commas that is useful in many contexts, profiles, and applications. Of course, it would be a better config file format if it supported comments, but people use it even despite that. I think we should try to understand the reasons for that rather than just telling people they’re doing it wrong.
  - foepys 7y ago
    The reason for that is that there is often a JSON parser library available for any language (especially JavaScript) but no ini or YAML config parser. So people use JSON because it's already easily accessible. JSON is one of the worst config formats, even worse than the Apache or nginx config formats. Not being able to simply comment out a config line temporarily for testing purposes or to leave a explanatory comment for special setting is simply bad.
    - vimslayer 7y ago
      Though most tools that use "JSON" as the config format actually use some superset of JSON, like JSON5, and do support comments. eslintrc, babelrc, vscode config... pretty much every JS tool configuration apart from package.json. I don't know why people would prefer that over YAML or others but at least you can actually add comments in them and the reason for their popularity doesn't seem to be baked in parser support because these tools are adding their additional "JSON" parsing anyway.
      - abiogenesis 7y ago
        I have a hard time remembering YAML syntax (am I constructing a list or a dict now? Oh well, better look it up) and I know for a fact that it's not just me. JSON is much simpler.
- yellowapple 7y ago
  XML is frequently used as a computer-to-computer interchange format, and it has comments.
- didibus 7y ago
  Json? A binary computer-to-computer interchange format? Do we use the same Json me and you? > Json is an open standard file format, and data interchange format, that uses human-readable text to store and transmit data objects - https://en.m.wikipedia.org/wiki/JSON https://en.m.wikipedia.org/wiki/JSON Json is text based, and meant for storage and transmission in a human readable format.
jve 7y ago
One must not forget JSON (JavaScript Object Notation) had to be Javascript compatible. It was almost. That is one of the main features. It could be eval'ed back into JS object after all. > Although Douglas Crockford originally asserted that JSON is a strict subset of JavaScript, his specification actually allows valid JSON documents that are not valid JavaScript; JSON allows the Unicode line terminators U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR to appear unescaped in quoted strings. > JSON is a strict subset of ECMAScript as of the language's 2019 revision. https://en.m.wikipedia.org/wiki/JSON#Data_portability_issues https://en.m.wikipedia.org/wiki/JSON#Data_portability_issues
ergothus 7y ago
I have hated the lack of comments so many times. But crockfird said it was done to keep the parsing simple (and thus secure), and between seeing how XML has it, and seeing how poorly many json parsing implementations are despite this simplicity, I have begrudgingly decided to accept it. Still wish there was a way without those problems though.
- hajile 7y ago
  It had NOTHING to do with the simplicity of the parser. He's said in his lectures that the real reason was that he wanted to prevent someone hiding custom pre-processor data in the comments and causing incompatibility. I think this was stupid. First, it happens anyway to some extent with people just using custom byte encodings for "strings". Second, using comments for metadata could be useful -- even if optional. For example, adding types after strings to specify things like the date format.

JSON is a binary computer-to-computer interchange format. No computer-to-computer interchange format has comments. The problem with JSON is that it's just human-readable enough that people think it's a config file format. It's not.

knodi123 7y ago
What are the material differences between a config file format, and a machine-to-machine only format?
- inetknght 7y ago
  Well, for one: most config file formats specifically include a method for the user to add bytes to the data which won't be parsed or interpreted. In JSON... you might try adding a {"comment": "this is a bad way to comment"} object or key/value and hope you don't collide with an object's dedicated comment field, and also don't cause the parser to raise an error for having a field which it didn't expect.
- korijn 7y ago
  The key difference is the target audience. The format's "UX", so to speak, is optimized for the target audience (machine or human). @jrockway makes an excellent point.
  - mark-r 7y ago
    Why must those be mutually exclusive? There's value in being understandable by both.
    - nitrogen 7y ago
      Having comments in a "wire format" provides a means for the spec to become meaningless as random applications start using comments to convey information (or exfiltrate data) that other applications cannot parse correctly.
      - mark-r 7y ago
        There should be a special place in hell reserved for people who use comments to convey machine readable information. The whole point of a comment is to provide something that has no semantic meaning.
- haggy 7y ago
  Config files are typically a 'load once, read many" pattern. Machine to machine communication protocols can be VERY high rate and over the network so they need to be highly efficient both in memory footprint and serialization overhead.
  - iainmerrick 7y ago
    So... JSON isn’t great as a machine to machine protocol, then? So I guess it must be a config format after all!
- robotnikman 7y ago
  I would think being able to have comments is a big one, so you at lease have an idea of what changes what in a config file.
mark-r 7y ago
Any format that can be edited with a text editor and retain proper formatting should be able to have embedded comments. No reason not to, and it can come in handy sometimes.
- ghayes 7y ago
  The argument, originally, I believe was that comments might be hacked to “extend” JSON with various additions (e.g. dates via an end of line marker). Comments were excluded to keep the format stable, which, FWIW, has worked.
  - ric2b 7y ago
    That's a bad argument, since you can still do that with "magic" fields or metadata fields.
    - deleted 7y ago
      [deleted]
btilly 7y ago
No computer-to-computer interchange format has comments. I call BS. As a counterexample search for the word "comment" in https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. Or are you saying that http is not a computer-to-computer interchange format?
- jrockway 7y ago
  You call BS because the HTTP/1.1 standard calls pieces of text that contain the name of the software at the other end of the connection "comments"? (To those that didn't read the spec, it uses the word comment to refer to the values in the User-Agent, Server, and Via headers.) It turns out these "comments" were a disaster and user agents are moving away from even providing them. You put "firefox" in the user-agent header, and web servers would read the comment and send you "your browser doesn't work" instead of the actual document. That did not make for a very compatible web... turns out comments in machine-to-machine communication are a bad idea.
  - deleted 7y ago
    [deleted]
  - btilly 7y ago
    Yes, comments tend to be turned over time into hints, directives, etc, etc, etc. But that doesn't change the fact that people put comments into machine protocols. For another example, lots of machine to machine protocols specify XML. Such as SOAP. They therefore all support comments. In accord to the general trend, eventually they get abused into having a semantic meaning. For example https://support.ptc.com/help/windchill/wc111_hc/whc_en/index.html#page/Windchill_Help_Center/IEUG_SOAPWritingTasks_IEUG_SOAPComments.html https://support.ptc.com/help/windchill/wc111_hc/whc_en/index... shows how one system uses comments in SOAP to create documentation and a WSDL that lets interfaces to your code to be automatically generated. And so comments eventually become executable. But that doesn't change the fact that comments can exist in machine to machine formats.
    - Mikhail_Edoshin 7y ago
gameswithgo 7y ago
Either it is a terrible format because it is such a massively wasteful (in terms of payload size and cpu overhead to serialize and deserialize) computer to computer interchange format, or it is terrible because it doesn't have comments.
- jrockway 7y ago
  Yeah, it's not a very good computer-to-computer format. No bytes type. No integer type. No Any->Any maps. Being bad at something doesn't automatically make you good at something else, and JSON is no exception. It's bad at everything except being popular. You have to look at JSON in a historical context to understand it. It exists so that someone could get some data into their Javascript program with "eval". It was then standardized so that you didn't need a full Javascript engine to understand it, because Python and Perl and Ruby didn't have one, and it turned out that evalling random data from the Internet was a security disaster. Does that make it a good human-readable config file? Nope. Does that make it a good interface definition language? Nope. It exists because it got popular early, and now we're stuck with it. Now it's too late to apply band-aids to make it a human-readable config language or a good computer-to-computer interchange format, because you will always have old parsers around and people will naturally want to target those. Trust me, 99% of developers will moan when you tell them that they have to use GRPC+Protos to access your API. They will be equally mad about your JSON extension that has comments and integers in it, because the dialect of Brainfuck they use for all their projects doesn't have a library that supports those extensions and their editor can't syntax-highlight it or autoformat it. I would like to give you a solution to this problem, but there isn't one. JSON "won", but it's bad at everything except being well-understood. That seems to be all that people really care about.
metaloha 7y ago
JSON isn't binary, it's text-based and human-readable by design (similar to YAML in that sense). JSONB is a binary variant, though, potentially more suitable for machine-to-machine communication and stores more efficiently in databases as a BLOB.
iainmerrick 7y ago
The problem with JSON is that it's just human-readable enough that people think it's a config file format. It's not. That attitude is misguided. Many people do in fact use JSON as a config file format, so it is a config file format. Real world usage outweighs prescriptions about what is and isn’t correct. Looking at the first standardized JSON spec, it’s not particularly prescriptive about usage, simply saying: JSON is syntax of braces, brackets, colons, and commas that is useful in many contexts, profiles, and applications. Of course, it would be a better config file format if it supported comments, but people use it even despite that. I think we should try to understand the reasons for that rather than just telling people they’re doing it wrong.
- foepys 7y ago
  The reason for that is that there is often a JSON parser library available for any language (especially JavaScript) but no ini or YAML config parser. So people use JSON because it's already easily accessible. JSON is one of the worst config formats, even worse than the Apache or nginx config formats. Not being able to simply comment out a config line temporarily for testing purposes or to leave a explanatory comment for special setting is simply bad.
  - vimslayer 7y ago
    Though most tools that use "JSON" as the config format actually use some superset of JSON, like JSON5, and do support comments. eslintrc, babelrc, vscode config... pretty much every JS tool configuration apart from package.json. I don't know why people would prefer that over YAML or others but at least you can actually add comments in them and the reason for their popularity doesn't seem to be baked in parser support because these tools are adding their additional "JSON" parsing anyway.
    - abiogenesis 7y ago
      I have a hard time remembering YAML syntax (am I constructing a list or a dict now? Oh well, better look it up) and I know for a fact that it's not just me. JSON is much simpler.
yellowapple 7y ago
XML is frequently used as a computer-to-computer interchange format, and it has comments.
didibus 7y ago
Json? A binary computer-to-computer interchange format? Do we use the same Json me and you? > Json is an open standard file format, and data interchange format, that uses human-readable text to store and transmit data objects - https://en.m.wikipedia.org/wiki/JSON https://en.m.wikipedia.org/wiki/JSON Json is text based, and meant for storage and transmission in a human readable format.

jve 7y ago

One must not forget JSON (JavaScript Object Notation) had to be Javascript compatible. It was almost. That is one of the main features. It could be eval'ed back into JS object after all. > Although Douglas Crockford originally asserted that JSON is a strict subset of JavaScript, his specification actually allows valid JSON documents that are not valid JavaScript; JSON allows the Unicode line terminators U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR to appear unescaped in quoted strings. > JSON is a strict subset of ECMAScript as of the language's 2019 revision. https://en.m.wikipedia.org/wiki/JSON#Data_portability_issues https://en.m.wikipedia.org/wiki/JSON#Data_portability_issues

ergothus 7y ago

I have hated the lack of comments so many times. But crockfird said it was done to keep the parsing simple (and thus secure), and between seeing how XML has it, and seeing how poorly many json parsing implementations are despite this simplicity, I have begrudgingly decided to accept it. Still wish there was a way without those problems though.

hajile 7y ago
It had NOTHING to do with the simplicity of the parser. He's said in his lectures that the real reason was that he wanted to prevent someone hiding custom pre-processor data in the comments and causing incompatibility. I think this was stupid. First, it happens anyway to some extent with people just using custom byte encodings for "strings". Second, using comments for metadata could be useful -- even if optional. For example, adding types after strings to specify things like the date format.