4 ms·

For good reason though. From Crockford: > I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would

For good reason though. From Crockford: > I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. via https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...

taeric 10y ago
I'd say "for reasons" not necessarily "good" ones. In particular, I think the jury is still out. The hacks that people have done to get comments into npm files are really quite illuminating.
MichaelGG 10y ago
It's funny. He says use a preprocessor to remove comments. Thus not using JSON. It's almost a joke. Except Microsoft does exactly that in their hip project.json format. Double quotes everywhere are more annoying to read than end tags. If we're going to invent nonstandard formats, why not remove the redundant tag name in the XML end tag. Problem solved.
- rendaw 10y ago
  My own contribution to the world's specification bloat: luxem https://github.com/rendaw/luxem https://github.com/rendaw/luxem A perhaps lightly more rigorous specification: https://github.com/Rendaw/luxemj/blob/master/src/main/resources/luxem.pidgoon https://github.com/Rendaw/luxemj/blob/master/src/main/resour... It allows optional quotes and comments, plus trailing "," and element type specifications. I think it's easier to read and hand-write, as well as write a parser/generator.
  - nilliams 10y ago
    Looks like a good take. Your readme would benefit from an example of what luxem looks like, ideally the first thing I'd see, below a short tagline, rather than having to read a lot of text and try to picture what you're describing.
gkya 10y ago
What good reason? Many programming languages have tools that parse comments for various things. With that 'good reason' we should remove comments from all programming languages. Comments wouldn't be usefull (mostly) for data sent on the wire --and JSON is quite good for that-- but for configuration files, they're indispensable. INI (like git's) is way better of a configuration format than JSON. Easier both to read and to write.
- nine_k 10y ago
  For sending things over the wire, a few way more efficient formats exist. JSON's appeal was simplicity and human-readability. The first goal is achieved OK; the second, so-so.

taeric 10y ago

I'd say "for reasons" not necessarily "good" ones. In particular, I think the jury is still out. The hacks that people have done to get comments into npm files are really quite illuminating.

MichaelGG 10y ago

It's funny. He says use a preprocessor to remove comments. Thus not using JSON. It's almost a joke. Except Microsoft does exactly that in their hip project.json format. Double quotes everywhere are more annoying to read than end tags. If we're going to invent nonstandard formats, why not remove the redundant tag name in the XML end tag. Problem solved.

rendaw 10y ago
My own contribution to the world's specification bloat: luxem https://github.com/rendaw/luxem https://github.com/rendaw/luxem A perhaps lightly more rigorous specification: https://github.com/Rendaw/luxemj/blob/master/src/main/resources/luxem.pidgoon https://github.com/Rendaw/luxemj/blob/master/src/main/resour... It allows optional quotes and comments, plus trailing "," and element type specifications. I think it's easier to read and hand-write, as well as write a parser/generator.
- nilliams 10y ago
  Looks like a good take. Your readme would benefit from an example of what luxem looks like, ideally the first thing I'd see, below a short tagline, rather than having to read a lot of text and try to picture what you're describing.

gkya 10y ago

What good reason? Many programming languages have tools that parse comments for various things. With that 'good reason' we should remove comments from all programming languages. Comments wouldn't be usefull (mostly) for data sent on the wire --and JSON is quite good for that-- but for configuration files, they're indispensable. INI (like git's) is way better of a configuration format than JSON. Easier both to read and to write.

nine_k 10y ago
For sending things over the wire, a few way more efficient formats exist. JSON's appeal was simplicity and human-readability. The first goal is achieved OK; the second, so-so.