The reason never made much sense, anything can be abused, and the comment use case is easily way more important, and your suggestion doesn't help with eg syntax highlighting tools for your config that will treat comments as syntax errors, and also lose the ability to roundtrip, so your app can't edit user configs

That doesn't make it a good reason. People are placing those directives into json docs anyway, but instead they're relying on nobody causing a namespace collision with their special key whos associated value has the directives of interest.

FWIW, I'm well aware of Crockford's rationale, I think it's some of the dumbest rationalization I've heard, and time has shown that it was a giant mistake.

Trying to prevent programmers from doing something "because they may 'misuse' comments" is asinine to the extreme. This is not like removing a footgun, it's trying to dictate how you think programming should be done. This is particularly hilarious because I've instead seen tons of horribly hacky workarounds for JSON's lack of comments, e.g. "fake" object entries like "__previousKey_comment": "this is a comment for previous key", or even worse, putting two entries with the same key since the second key should "win", and thus making the first entry the comment.

As for his second point, "Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser." - just look at the everlasting shit show that is package.json since it can't support comments, because lots of NPM tools actually write to package.json, so there is no guarantee that other tools will be able to read package.json if it includes comments.

I think the thing that I hate most about Crockford's rationalization of not having comments is that you have to have your head stuck 10 feet in the sand to pretend that somehow the lack of comments is a good thing with the benefit of hindsight. I guess I could understand if Crockford's position was "Yeah, originally I thought it was better to keep them out because I was concerned about misuse, but now in retrospect to see the much larger problems it causes, and I realize it was a mistake." But instead he just keeps pushing his original crappy opinion on this topic.

So instead of comments with parsing directives, people use underscore prefixed keys to keep metadata and comments, that's not a win at all

We should call this "The Crockford Fallacy". Destroying something valuable in fear of a perceived threat.

One way to bifurcate the world is that there are people who tend to restrict options to prevent misuse vs. people who tend to enable options to the positive uses easier. I fall in the latter camp. Preventing errors by restricting options also prevents positive uses that make life better.

We get to choose what approach we take. I prefer the "give them the rope they might need" philosophy. If they hang themselves, oh well.

Software developers very much so care about best practices.

All that needed to be said was, "Using comment programmatically is bad practice. Don't do it."

> I removed comments from JSON because I saw people were using them to hold parsing directives

there's always someone putting actual logic in comments, and when I rule the world, those people are all going to be put on an island by themselves and they're going to have to deal with each other.

It might be abused and you can just pipe it through a preprocessor are not very good reasons.

Abuse of comments is not an academic, theoretical consideration.

https://www2.jwz.org/doc/cddb.html

(Unfortunately, because jwz blocks HN referrals, you can't click on this link, but will need to copy it into the address bar)

And that is fine reasoning, the workaround is not for me… but the larger issue is an inventor kneecapping something by stating how you should use it.

It’s not like there isn’t another side to this argument.

That's a terrible reasoning for requiring an extra toolchain.