6 ms·

Between commas and comments, I would personally vote for comments. JSON is, unfortunately, used in many places as a configuration language (think package.json)

Between commas and comments, I would personally vote for comments. JSON is, unfortunately, used in many places as a configuration language (think package.json). Sometimes you have to comment out a section for some experiment. Many times, you want to explain why you included this or that in the config. Hence comments. The trailing commas issue is slightly annoying, but an order of magnitude less important IMHO.

mabbo 9y ago
Why not both?
- flamedoge 9y ago
  Protocol Buffer?
  - candiodari 9y ago
    In protocol buffers, you don't have commas. Also comments go where they belong, in the schema ...
sneak 9y ago
There is a damned good reason JSON does not allow comments. It's not an accident.
- tempestn 9y ago
  So can you fill the rest of us in on the reason then?
  - rootlocus 9y ago
    You can blame Crockford for that: [1] TLDR: Basically, in a typical Crockford move, he saw people were using them in a specific way he did not like (to store parsing parameters), so he removed them entirely. I say "typical Crockford" because some of his JS linting rules are gratuitous overkill in my opinion. He also suggests that if you want comments, you should pipe the config file through a minifier that removes them before parsing. Doesn't seem like that much of a good reason to me, but whatever. 1. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
    - seanwilson 9y ago
      Yeah...that's frustrating. For a Chrome Extension manifest JSON file I was recently editing, you have to enter a description field that I found out is limited to around 100 characters after a failed upload. I wanted to add a comment above this field so myself and anyone else editing the file was aware of this in the future (a good use of comments in my opinion). I'm not going go through the hassle of a build step to do this. Programming languages allow comments for a reason and I don't see what's so different about JSON.
      - DaiPlusPlus 9y ago
        If the consuming program allows it, you can fake a comment by storing it as a JSON property value: { "myComment": "This is a comment!", "realValue": 1 }
        seanwilson 9y ago
        That's what I did actually. I don't like it though. A comment is really saying "this is a note for the reader that isn't used at runtime". Putting a comment in as a value goes against that and it uses up memory when the file is read in.
        rpdillon 9y ago
        On the flip side, I've always found it useful when debugging at a REPL to be able to read various kinds of metadata about objects, including documentation. Clojure is one example of this, but I wouldn't mind seeing it elsewhere as well. https://clojure.org/reference/metadata https://clojure.org/reference/metadata
        seanwilson 9y ago
        Hmm, so I'm thinking about cases where you have 10K objects and you wouldn't want the metadata duplicated and attached to all of those. Would that happen in Clojure?
    - 9y ago
  - tonyg 9y ago
    They tend not to survive roundtripping well, for example. JSON describes data; comments are metadata. To do them well you'd have to bring them into JSON infoset, such as it is. (ETA: JSON already has problems with canonicalization. Adding comments makes this worse. Are they in or out of the equivalence over JSON terms?)
- LoSboccacc 9y ago
  gotta love the hn community, downvoting things that are correct but hurt them feels
  - Illniyar 9y ago
    no, we downvote things that state an opinion as fact without even an attempt at explaining why, especially when done in a tone that is aggressive and disrespectful.
    - LoSboccacc 9y ago
      It's not an opinion however. JSON is a standard. Kinda worries me professionals use it without having a clue.
      - mrunkel 9y ago
        The reason why something did or didn't make it into a standard are definitely opinions. All sneak had to do was to provide a link to the "damned good reason."
      - Illniyar 9y ago
        That JSON has a "good reason" for disallowing comments is an opinion, it could be a popular, well-known and established opinion or it could be completely uninformed. To know the difference one must explain it. Also standards change, and professionals use their tools in ways the original creators did not imagine a lot, that doesn't make them clueless. Heck, even JSON is a result of professionals misusing a programming language syntax for a serialization protocol.
        wpietri 9y ago
        Your opinion that all opinions must be explained up front was not explained up front.
- krapp 9y ago
  Not liking comment macros is not a "damned good reason," it's just a reason. People could still do that in JSON anyway the same way they hack in comments - just add them as strings.
crdoconnor 9y ago
It may be used as such but it shouldn't be. YAML serves this purpose much better. JSON works better as a language independent serialization format that is incidentally readable.
- sametmax 9y ago
  Yeah json is a fact of life, the fact yaml exists doesn't change that. Actually, toml is even better than yaml and yet...
  - crdoconnor 9y ago
    TOML's array/table syntax is kind of confusing, especially when you're a few levels deep. Having meaningful whitespace in YAML makes it clearer. It's also kind of messy when you have a lot of multiline strings.
    - NateDad 9y ago
      Meaningful whitespace is horrid. I speak from 3.5 years of working on s project that exclusively used yaml as configuration. Yaml is horrid. Toml is way better. Yes, multilayered objects in toml are ugly. Don't make your users created multilayered objects for their configuration. That's just a bad UX regardless of the language.
      - guitarbill 9y ago
        > Meaningful whitespace is horrid Millions of Python programmers might disagree, not to mention that most programmers using languages with meaningless whitespace (as far as the computer is concerned) still put whitespace in there, because humans. And it isn't like INI is a great experience, either. Flat configs suck in their own ways.
        krapp 9y ago
        It's weird that a language with the mantra "explicit is better than implicit" has, as a core feature, braces implied by the negative space of the left-hand margin of a text editor. >And it isn't like INI is a great experience, either. Flat configs suck in their own ways. Yes, INI isn't great, but people who object to significant whitespace don't object to the "whitespace" part, they object to the "significant" part. That code could not compile or have scope errors because of one extra space or because a space replaced a tab just seems absurd to some people. This is something about which reasonable people can disagree.

mabbo 9y ago

Why not both?

flamedoge 9y ago
Protocol Buffer?
- candiodari 9y ago
  In protocol buffers, you don't have commas. Also comments go where they belong, in the schema ...

sneak 9y ago

There is a damned good reason JSON does not allow comments. It's not an accident.

tempestn 9y ago
So can you fill the rest of us in on the reason then?
- rootlocus 9y ago
  You can blame Crockford for that: [1] TLDR: Basically, in a typical Crockford move, he saw people were using them in a specific way he did not like (to store parsing parameters), so he removed them entirely. I say "typical Crockford" because some of his JS linting rules are gratuitous overkill in my opinion. He also suggests that if you want comments, you should pipe the config file through a minifier that removes them before parsing. Doesn't seem like that much of a good reason to me, but whatever. 1. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
  - seanwilson 9y ago
    Yeah...that's frustrating. For a Chrome Extension manifest JSON file I was recently editing, you have to enter a description field that I found out is limited to around 100 characters after a failed upload. I wanted to add a comment above this field so myself and anyone else editing the file was aware of this in the future (a good use of comments in my opinion). I'm not going go through the hassle of a build step to do this. Programming languages allow comments for a reason and I don't see what's so different about JSON.
    - DaiPlusPlus 9y ago
      If the consuming program allows it, you can fake a comment by storing it as a JSON property value: { "myComment": "This is a comment!", "realValue": 1 }
      - seanwilson 9y ago
        That's what I did actually. I don't like it though. A comment is really saying "this is a note for the reader that isn't used at runtime". Putting a comment in as a value goes against that and it uses up memory when the file is read in.
        rpdillon 9y ago
        On the flip side, I've always found it useful when debugging at a REPL to be able to read various kinds of metadata about objects, including documentation. Clojure is one example of this, but I wouldn't mind seeing it elsewhere as well. https://clojure.org/reference/metadata https://clojure.org/reference/metadata
        seanwilson 9y ago
        Hmm, so I'm thinking about cases where you have 10K objects and you wouldn't want the metadata duplicated and attached to all of those. Would that happen in Clojure?
  - 9y ago
- tonyg 9y ago
  They tend not to survive roundtripping well, for example. JSON describes data; comments are metadata. To do them well you'd have to bring them into JSON infoset, such as it is. (ETA: JSON already has problems with canonicalization. Adding comments makes this worse. Are they in or out of the equivalence over JSON terms?)
LoSboccacc 9y ago
gotta love the hn community, downvoting things that are correct but hurt them feels
- Illniyar 9y ago
  no, we downvote things that state an opinion as fact without even an attempt at explaining why, especially when done in a tone that is aggressive and disrespectful.
  - LoSboccacc 9y ago
    It's not an opinion however. JSON is a standard. Kinda worries me professionals use it without having a clue.
    - mrunkel 9y ago
      The reason why something did or didn't make it into a standard are definitely opinions. All sneak had to do was to provide a link to the "damned good reason."
    - Illniyar 9y ago
      That JSON has a "good reason" for disallowing comments is an opinion, it could be a popular, well-known and established opinion or it could be completely uninformed. To know the difference one must explain it. Also standards change, and professionals use their tools in ways the original creators did not imagine a lot, that doesn't make them clueless. Heck, even JSON is a result of professionals misusing a programming language syntax for a serialization protocol.
      - wpietri 9y ago
        Your opinion that all opinions must be explained up front was not explained up front.
krapp 9y ago
Not liking comment macros is not a "damned good reason," it's just a reason. People could still do that in JSON anyway the same way they hack in comments - just add them as strings.

crdoconnor 9y ago

It may be used as such but it shouldn't be. YAML serves this purpose much better. JSON works better as a language independent serialization format that is incidentally readable.

sametmax 9y ago
Yeah json is a fact of life, the fact yaml exists doesn't change that. Actually, toml is even better than yaml and yet...
- crdoconnor 9y ago
  TOML's array/table syntax is kind of confusing, especially when you're a few levels deep. Having meaningful whitespace in YAML makes it clearer. It's also kind of messy when you have a lot of multiline strings.
  - NateDad 9y ago
    Meaningful whitespace is horrid. I speak from 3.5 years of working on s project that exclusively used yaml as configuration. Yaml is horrid. Toml is way better. Yes, multilayered objects in toml are ugly. Don't make your users created multilayered objects for their configuration. That's just a bad UX regardless of the language.
    - guitarbill 9y ago
      > Meaningful whitespace is horrid Millions of Python programmers might disagree, not to mention that most programmers using languages with meaningless whitespace (as far as the computer is concerned) still put whitespace in there, because humans. And it isn't like INI is a great experience, either. Flat configs suck in their own ways.
      - krapp 9y ago
        It's weird that a language with the mantra "explicit is better than implicit" has, as a core feature, braces implied by the negative space of the left-hand margin of a text editor. >And it isn't like INI is a great experience, either. Flat configs suck in their own ways. Yes, INI isn't great, but people who object to significant whitespace don't object to the "whitespace" part, they object to the "significant" part. That code could not compile or have scope errors because of one extra space or because a space replaced a tab just seems absurd to some people. This is something about which reasonable people can disagree.