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.
JSON works better as a language independent serialization format that is incidentally readable.
It's also kind of messy when you have a lot of multiline strings.
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.
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.
>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.
The lack of braces enforces a certain style - something that can be found throughout Python. For example, the lack of multi-line lambda statements.
> braces implied by the negative space
It's easier to think of it in the same way that the compiler does: indent and dedent. Indent? Creating a new scope. Dedent? Exiting the current scope. All of the "constant 4 spaces" and "spaces instead of tabs" simply makes it easier for humans to interpret the indent and dedents visually.
In my experience in writing code in multiple languages: even when using braces you, the coder, still effectively require indentation to visually parse blocks. Yes, copying and pasting code is a touch harder, and most text editors are too lazy to parse for indents and dedents, but the first is mitigated by applying basic DRY principles, the second by installing a python-aware plugin.
I think the significant whitespace is a pragmatism thing. If you're already doing it, do it consistently, if you're already doing it consistently do you really need brackets? The answer is no, and the added bonus is you (and everybody else) is forced to do the whitespace consistently. I'll take a consistently formatted codebase over inconsistencies any day!
Things can change. Push the world forward. Think of little things you can do that make the world of development the world you want to be in.
But of course toml is superior to both because it has comments and no significant white space and the comma at the end of lists is optional.
TBH, common JSON implementations have their problems too. Integer size and integer/float (de-)serialization tend to be somewhat interesting at times. I've even seen implementations serializing JavaScript objects as JSON (e.g., {foo: 2} instead of {"foo": 2})
JSON doesn't have "integers" and "floats", it has "numbers" which are are expressed in decimal scientific notation. There's no guarantee an implementation will let you distinguish what was parsed, and the numerical precision and range of interoperable JSON is undefined.
The bottom line is JSON is a risky proposition for financial or scientific data exchange.
And before you say JSON numbers are de-facto IEEE754 doubles, bare in mind that most JSON implementations can't roundtrip them properly.[0] A symptom of everybody wanting to write a toy implementation.
[0] https://rawgit.com/miloyip/nativejson-benchmark/master/sampl...
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/RK8qyGVaG...
{ "myComment": "This is a comment!", "realValue": 1 }Why not use js for config instead of json? It's your app and your config so if you want it to look like json + comments + trailing comma you can. With so many options for config files like yaml, xml, heck even sqlite it does seem a bit silly how much json is used. Herd mentality.
Crockford probably didn't think it would take off like it did, but with hindsight comments would have been the pragmatic choice IMO.
(ETA: JSON already has problems with canonicalization. Adding comments makes this worse. Are they in or out of the equivalence over JSON terms?)
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.