5 ms·

Dings XML for crappy commenting syntax then gives JSON a pass for not supporting comments at all. I love JSON, but it does have it's issues.

masklinn 14y ago
On the other hand, comments were explicitly excluded from JSON by Crockford (with the thinking — probably correct — that they'd be abused to embed such things as parsing directives or other out-of-band content)
- TazeTSchnitzel 14y ago
  I believe he was correct at the time, he removed them once people started using them for parsing directives. (JSON hasn't always been frozen)
  - angersock 14y ago
    Having seen/used the rudimentary commenting mechanism in Wavefront .OBJ files (a 3D interchange format) to stuff in more modern information (tangents, additional UV channels, etc. etc.), I can say that comments can help a format live on well past its expiry date. That said, I will not pretend for a second that this is a good idea. Crockford did the right thing.
wvenable 14y ago
JSON not having comments is a benefit when used for it's primary purpose: information exchange. JSON is not a great format for configuration files or static documents even though it's increasingly used for it.
- ishbits 14y ago
  YAML is better suited for configuration files.
  - joe_the_user 14y ago
    Yaml is not good for configuration files because it is not easily human-editable. It seems "easy" but meaningful whitespace is a cluster-fck. Edit: I have been looking for reasonable configuration file formats for a while. Json actually has pretty bad human-readability at any scale because of its quoted key-values. Yaml is easily readable but when a user tries to change anything, things go to hell. The humble ini-file has won so far. It's limited and not fully standardized but it is human readable and human writable. I'd love see something better but human readability/writable is going trump all sorts of cleverness. Edit2: From http://en.wikipedia.org/wiki/YAML http://en.wikipedia.org/wiki/YAML "The specific number of spaces in the indentation is unimportant as long as parallel elements have the same left justification and the hierarchically nested elements are indented further." Yeah, a user of your software is going to be able to understand when they mess up on that rule, riiiight. Screw Yaml.
    - chipsy 14y ago
      I rolled my own format specifically for configuration. No significant whitespace, delimiters may dangle, and the parser implementation can be configured to accept very high ambiguity(including, if desired, mixtures of sequence and key-value data). https://github.com/triplefox/triad/blob/master/dev/com/ludamix/triad/format/TriadConfig.hx https://github.com/triplefox/triad/blob/master/dev/com/ludam... A "real-world" example https://github.com/triplefox/triad/blob/master/examples/Assets/graphics.tc https://github.com/triplefox/triad/blob/master/examples/Asse...
    - jscn 14y ago
      It seems "easy" but meaningful whitespace is a cluster-fck. Tell that to everyone using Python. If your editor can't handle meaningful whitespace transparently, it sounds like you need a better editor.
      - sigzero 14y ago
        Python is a programming language. Worlds of difference there.
      - 14y ago
mikeash 14y ago
I don't know that it applies here, but sometimes it is better to not have a feature at all than to have it badly.
pippy 14y ago
Explicit is better than implicit. If you have to explain something you've probably written the JSON wrong. You can always do this: { 'people' : 10, 'desc': 'People who will attend' }
- mcantelon 14y ago
  >Explicit is better than implicit. Which is why not intermingling comments with data makes sense. >If you have to explain something you've probably written the JSON wrong. You could say the same about code: "if you need to comment then your code isn't clear enough". In reality sometimes commenting code or data is helpful.
rdtsc 14y ago
JSON not having comments is a deliberate design decision (a feature if you want). The reason is if it supported comments, they would have ended up being used to for meta languages and parse directives that would have created JSON documents that could not be parsed or processed by all JSON parsers -- it would have fragmented the JSON ecosystem quite a bit. So it might seem like an accidental bug or omission but it is not it is on purpose and I agree with it.

masklinn 14y ago

On the other hand, comments were explicitly excluded from JSON by Crockford (with the thinking — probably correct — that they'd be abused to embed such things as parsing directives or other out-of-band content)

TazeTSchnitzel 14y ago
I believe he was correct at the time, he removed them once people started using them for parsing directives. (JSON hasn't always been frozen)
- angersock 14y ago
  Having seen/used the rudimentary commenting mechanism in Wavefront .OBJ files (a 3D interchange format) to stuff in more modern information (tangents, additional UV channels, etc. etc.), I can say that comments can help a format live on well past its expiry date. That said, I will not pretend for a second that this is a good idea. Crockford did the right thing.

wvenable 14y ago

JSON not having comments is a benefit when used for it's primary purpose: information exchange. JSON is not a great format for configuration files or static documents even though it's increasingly used for it.

ishbits 14y ago
YAML is better suited for configuration files.
- joe_the_user 14y ago
  Yaml is not good for configuration files because it is not easily human-editable. It seems "easy" but meaningful whitespace is a cluster-fck. Edit: I have been looking for reasonable configuration file formats for a while. Json actually has pretty bad human-readability at any scale because of its quoted key-values. Yaml is easily readable but when a user tries to change anything, things go to hell. The humble ini-file has won so far. It's limited and not fully standardized but it is human readable and human writable. I'd love see something better but human readability/writable is going trump all sorts of cleverness. Edit2: From http://en.wikipedia.org/wiki/YAML http://en.wikipedia.org/wiki/YAML "The specific number of spaces in the indentation is unimportant as long as parallel elements have the same left justification and the hierarchically nested elements are indented further." Yeah, a user of your software is going to be able to understand when they mess up on that rule, riiiight. Screw Yaml.
  - chipsy 14y ago
    I rolled my own format specifically for configuration. No significant whitespace, delimiters may dangle, and the parser implementation can be configured to accept very high ambiguity(including, if desired, mixtures of sequence and key-value data). https://github.com/triplefox/triad/blob/master/dev/com/ludamix/triad/format/TriadConfig.hx https://github.com/triplefox/triad/blob/master/dev/com/ludam... A "real-world" example https://github.com/triplefox/triad/blob/master/examples/Assets/graphics.tc https://github.com/triplefox/triad/blob/master/examples/Asse...
  - jscn 14y ago
    It seems "easy" but meaningful whitespace is a cluster-fck. Tell that to everyone using Python. If your editor can't handle meaningful whitespace transparently, it sounds like you need a better editor.
    - sigzero 14y ago
      Python is a programming language. Worlds of difference there.
    - 14y ago

mikeash 14y ago

I don't know that it applies here, but sometimes it is better to not have a feature at all than to have it badly.

pippy 14y ago

Explicit is better than implicit. If you have to explain something you've probably written the JSON wrong. You can always do this: { 'people' : 10, 'desc': 'People who will attend' }

mcantelon 14y ago
>Explicit is better than implicit. Which is why not intermingling comments with data makes sense. >If you have to explain something you've probably written the JSON wrong. You could say the same about code: "if you need to comment then your code isn't clear enough". In reality sometimes commenting code or data is helpful.

rdtsc 14y ago

JSON not having comments is a deliberate design decision (a feature if you want). The reason is if it supported comments, they would have ended up being used to for meta languages and parse directives that would have created JSON documents that could not be parsed or processed by all JSON parsers -- it would have fragmented the JSON ecosystem quite a bit. So it might seem like an accidental bug or omission but it is not it is on purpose and I agree with it.