6 ms·

I'm confident that everyone knows about XML and that you're a worse troll than I am. Nobody contests XML's capability. It was unpleasant to write and read.

nine_k 10y ago
Json forbids comments. It makes writing it much less pleasurable than it might be.
- coderholic 10y ago
  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.
- tcdent 10y ago
  Is it really that sacrilegious to just put your comments inside of a parseable data format? Python provides programmatic access to docstrings, for example, and it has many valid uses.
sdegutis 10y ago
The raw format may be. But with a good IDE it's pretty easy. Just like, well, most computer languages actually.
- throwaway284534 10y ago
  We don't always have the luxury of an IDE when working on a remote machine or debugging. Despite JSON's shortcomings, the developer community found it on the whole more pleasant to work with. It's the same argument that Lisp users make. The two are more expressive, more capable, more safe. It's also very dense and intimidating. You can come up with all the justifications you'd like. It won't win the hearts of developers.
- flukus 10y ago
  Even without an IDE, it's much easier to see where a scope ends with </tag> than it is with curly braces.
PeCaN 10y ago
It's a troll post, but the point stands: JSON is reinventing XML. XML is ugly, but complicated JSON isn't much better IMO. It has an only slightly less human-unfriendly syntax: Why do I have to use double quotes on keys? Why are there no comments? Then come things like schemas, queries, and transformations: XSD, XPath, and XSLT are very powerful tools. Their implementation sucks, but it's arguably better than people coming up with their own half-documented solution whenever they need something XSD/XPath/XSLT provides.
- hyperpallium 10y ago
  XML protects JSON: people needing extra power choose the complexity in the XML ecosystem, keeping JSON simple. The problem is usages that grow in their need for power over time, with high switching costs. Instead of choosing, they add pressure to XMLify the JSON ecosystem. JSON's doom seems distant but inevitable, but it will instead be defeated by the rise of yet another format.
- vmasto 10y ago
  > Why there are no comments? Here's the answer: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG... Not sure if I agree with it or not, nevertheless that was the reasoning.
- hannob 10y ago
  JSON has huge advantages from a security perspective. The feature-richness of XML is also a richness of sources of security vulnerabilities.
  - creshal 10y ago
    Is it even possible to make a 100% standards conforming parser that is not vulnerable to at least DoS attacks? (Automatically fetching XSDs e.g. sounds nice in practice, until you realize that it means your server will make HTTP requests to user-supplied URLs, so most parsers come with an option to disable it, which may or may not break documents relying on it.)

nine_k 10y ago

Json forbids comments. It makes writing it much less pleasurable than it might be.

coderholic 10y ago
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.
tcdent 10y ago
Is it really that sacrilegious to just put your comments inside of a parseable data format? Python provides programmatic access to docstrings, for example, and it has many valid uses.

sdegutis 10y ago

The raw format may be. But with a good IDE it's pretty easy. Just like, well, most computer languages actually.

throwaway284534 10y ago
We don't always have the luxury of an IDE when working on a remote machine or debugging. Despite JSON's shortcomings, the developer community found it on the whole more pleasant to work with. It's the same argument that Lisp users make. The two are more expressive, more capable, more safe. It's also very dense and intimidating. You can come up with all the justifications you'd like. It won't win the hearts of developers.
flukus 10y ago
Even without an IDE, it's much easier to see where a scope ends with </tag> than it is with curly braces.

PeCaN 10y ago

It's a troll post, but the point stands: JSON is reinventing XML. XML is ugly, but complicated JSON isn't much better IMO. It has an only slightly less human-unfriendly syntax: Why do I have to use double quotes on keys? Why are there no comments? Then come things like schemas, queries, and transformations: XSD, XPath, and XSLT are very powerful tools. Their implementation sucks, but it's arguably better than people coming up with their own half-documented solution whenever they need something XSD/XPath/XSLT provides.

hyperpallium 10y ago
XML protects JSON: people needing extra power choose the complexity in the XML ecosystem, keeping JSON simple. The problem is usages that grow in their need for power over time, with high switching costs. Instead of choosing, they add pressure to XMLify the JSON ecosystem. JSON's doom seems distant but inevitable, but it will instead be defeated by the rise of yet another format.
vmasto 10y ago
> Why there are no comments? Here's the answer: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG... Not sure if I agree with it or not, nevertheless that was the reasoning.
hannob 10y ago
JSON has huge advantages from a security perspective. The feature-richness of XML is also a richness of sources of security vulnerabilities.
- creshal 10y ago
  Is it even possible to make a 100% standards conforming parser that is not vulnerable to at least DoS attacks? (Automatically fetching XSDs e.g. sounds nice in practice, until you realize that it means your server will make HTTP requests to user-supplied URLs, so most parsers come with an option to disable it, which may or may not break documents relying on it.)