It's a pretty sensible policy, really. Corollary to Hyrum's Law - do not permit your API to have any behaviours, useful or otherwise, which someone might depend on but which aren't part of your design goals. For programmers in particular, who are sodding munchkins and cannot be trusted not to do something clever but unintended just because it solves a problem for them, that means aggressively hamstringing everything.

A flathead screwdriver should bend like rubber if someone tries to use it as a prybar.

> A flathead screwdriver should bend like rubber if someone tries to use it as a prybar.

While I admire his design goals, people will just work around it in a pinch by adding a "comment" or "_comment" or "_comment_${random_uuid}", simply because they want to do the job they need.

If your screwdriver bends like a rubber when prying, damn it, I'll just put a screw next to it, so it thinks it is used for driving screws and thus behaves correctly.

And we wonder why people are calling for licensed professional software engineers.

On one hand, it has made json more ubiquitous due to it's frozen state. On another hand, it forces everyone to move to something else and fragments progress. It would be much easier for people to move to json 2.0 rather than having hundreds of json + x standards. Everyone is just reinventing json with their own little twist that I feel sad that we haven't standardized to a single solution that doesn't go super crazy like xml.

I don't disagree with the choice, but seeing how things turned out I can't just help but look at the greener grass on the other side.

> A flathead screwdriver should bend like rubber if someone tries to use it as a prybar.

Better not let me near your JSON files then. I pound in wall anchors with the bottom of my drill if my hammer is not within arms reach.

JSON is used as config files and static resources all the time. These type of files really need comments. Preventing comments in JSON is punishing the wide majority to prevent a small minority from doing something stupid. But stupid gonna stupid, it's just condescending from Mister JSON to think he can do anything about it.

XML people were doing crazy things in the Java/.NET world and "<!--[if IE 6]>" was still a thing in HTML when JSON was being designed.

I also would have wanted comments, but I see why Crockford must have been skeptical. He just didn't want JSON to be the next XML.

Unrelated: why spaces inside the parentheses? It’s not the first time I see this, but this is incorrect!

Probably someone who writes C/C++ and formats their code that way

    if ( x == ( y + z ) * w ) {

Personally, I find it hard to read.

JSON doesn't have parentheses, but it does have braces and brackets. The JSON spec specifically allows spaces.

> Insignificant whitespace is allowed before or after any token.

I was talking about the parent comment, which has spaces inside the parenthesis (I do prefer no spaces inside brackets and braces in my JSONs, but that’s another story).