News for hackers. Stuff that matters.
Re:A modest proposal by tempestn on Saturday September 09, 2017 @05:56AM (#15206316)
So can you fill the rest of us in on the reason then?
Re:A modest proposal by rootlocus on Saturday September 09, 2017 @06:06AM (#15206353)
You can blame Crockford for that: [1]

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...

Re:A modest proposal by snarfy on Saturday September 09, 2017 @06:42AM (#15206462)
I think he wanted it to be something different than js, hence the focus on strictly data exchange.

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.

Re:A modest proposal by seanwilson on Saturday September 09, 2017 @06:28AM (#15206416)
Yeah...that's frustrating. For a Chrome Extension manifest JSON file I was recently editing, you have to enter a description field that I found out is limited to around 100 characters after a failed upload. I wanted to add a comment above this field so myself and anyone else editing the file was aware of this in the future (a good use of comments in my opinion). I'm not going go through the hassle of a build step to do this. Programming languages allow comments for a reason and I don't see what's so different about JSON.
Re:A modest proposal by DaiPlusPlus on Saturday September 09, 2017 @07:22AM (#15206570)
If the consuming program allows it, you can fake a comment by storing it as a JSON property value:

  { "myComment": "This is a comment!", "realValue": 1 }
Re:A modest proposal by seanwilson on Saturday September 09, 2017 @07:29AM (#15206588)
That's what I did actually. I don't like it though. A comment is really saying "this is a note for the reader that isn't used at runtime". Putting a comment in as a value goes against that and it uses up memory when the file is read in.
Re:A modest proposal by rpdillon on Saturday September 09, 2017 @10:23AM (#15207206)
On the flip side, I've always found it useful when debugging at a REPL to be able to read various kinds of metadata about objects, including documentation. Clojure is one example of this, but I wouldn't mind seeing it elsewhere as well.

https://clojure.org/reference/metadata

Re:A modest proposal by seanwilson on Saturday September 09, 2017 @10:48AM (#15207325)
Hmm, so I'm thinking about cases where you have 10K objects and you wouldn't want the metadata duplicated and attached to all of those. Would that happen in Clojure?
Re:A modest proposal by guitarbill on Saturday September 09, 2017 @09:44AM (#15207037)
Comments also are a bit tricky to preserve when programatically modifying data structures, so a destructive minifier approach makes sense. Although it's very Javascript, "let's make another utility you now need".

Crockford probably didn't think it would take off like it did, but with hindsight comments would have been the pragmatic choice IMO.

Re:A modest proposal by JaniceLeblanc on Saturday September 09, 2017 @08:03AM (#15206683)
It's an excelent reason in my opinion.
Re:A modest proposal by tonyg on Saturday September 09, 2017 @06:18AM (#15206386)
They tend not to survive roundtripping well, for example. JSON describes data; comments are metadata. To do them well you'd have to bring them into JSON infoset, such as it is.

(ETA: JSON already has problems with canonicalization. Adding comments makes this worse. Are they in or out of the equivalence over JSON terms?)