logoalt Hacker News

hn_throwaway_99 • 12/09/2024 • 6 replies • view on HN

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.

Replies

6510 • 12/09/2024

I one time by sort of accident coined a config format by parsing todo.txt It was so useful it stuck around for much longer than I had intended to. Rather than comment out stuff it just looks for "=" and ignores everything else.

   conf = {};
   configFile.split('\n').forEach( function(x){
      y = x.split(' ');
      if(y[1]=="=") conf[y[0]] = y[2];
   });
Everything is a comment with exception of lines like:

speed = 100 km/h

weight = 60 kg

maxBuffer = 200 chars (between 100 and 300 works best)

output: {"speed":100,"weight":60,"maxBuffer":200}

It had walls of text with headings and something configurable sprinkled in. Crockford would be screaming. lol

➕ show 1 reply
justmedep • 12/09/2024

I usually just add my comment as an additional field called _comment or something like that

➕ show 3 replies
milch • 12/09/2024

I've also seen parser directives inserted into the keys like `{ "fooBar__datetime": 123456780.0 }`, and many other creative workarounds

➕ show 1 reply
mp05 • 12/09/2024

@fat is that you?

➕ show 1 reply
leptons • 12/09/2024

When I think of how often and where JSON is used, as a data interchange format for APIs, in the browser, databases, and everywhere else - all the billions of bytes transferred in JSON every second - in all those use cases comments would be pointless and counterproductive and just take up storage space or bandwidth. That's JSON's primary use case in the world. It's only in the very few use cases specifically for programmers where comments would sort of be helpful in JSON, and most of those cases are not really that important to support when there are workarounds - structure your JSON well and you can include the comments as part of the JSON, and then you can even use the comments programmatically should that be useful (which I think is slightly more useful than storing knowledge in a JSON file as a comment).

>Trying to prevent programmers from doing something "because they may 'misuse' comments" is asinine to the extreme.

Programmers are often their own worst enemies. Some prefer rigid rulesets over less rigid freeform programming. See Typescript vs Javascript. No comments in JSON is just another example of over-rigidification, and some programmers love that.

>package.json since it can't support comments,

If you're needing to write comments in package.json, maybe you're not approaching package.json correctly? It's really for node things, not your things that you need to write comments about. I'm not even sure why someone would want to write comments in package.json. I get it with comments in other JSON files, but package.json probably should be left for nodejs things.

➕ show 1 reply
oneeyedpigeon • 12/09/2024

I just took a look at an example package.json file and it seemed fine — no 'comments' shoehorned in anywhere, meaningful key names that reduced the need for comments. Do you have an example of a package.json file that would be better if json supported comments?

➕ show 2 replies