6 ms·

Crockford regularly displays a stunning degree of tunnel vision. Without a standard format for comments, you have no reason whatsoever to expect the ad-hoc com

Crockford regularly displays a stunning degree of tunnel vision. Without a standard format for comments, you have no reason whatsoever to expect the ad-hoc comments in a JSON file made by anyone who isn't you to be styled like JavaScript comments. And if your response is "then everyone needs to use JavaScript-style comments", well, TA-DA, you've just added comments to the spec. You can't have it both ways. > It's imperative that the JWCC author explain what they find lacking in Doug's solution - stripping comments before handing off the a JSON parser If the syntax rules for adding comments are unspecified, then the the syntax rules for what to strip out are unspecified too!

ethanwillis 6y ago
If the rules are unspecified the only thing you wouldn't be able to put in comments are what is specified as JSON syntax. If you add minimal specifications for escape sequences then even that is allowed.
- BugsJustFindMe 6y ago
  > If you add specifications then Indeed.
tshaddox 6y ago
I wish JSON supported comments, but I don’t really understand your criticism. You say: > Without a standard format for comments, you have no reason whatsoever to expect the ad-hoc comments in a JSON file made by anyone who isn't you to be styled like JavaScript comments. But, since comments are not supported in JSON, you can expect JSON from external sources to contain no comments whatsoever. That’s precisely Crockford’s point: he didn’t want the format to have a comment syntax that works across different parties so that the only way to use comments is internally, i.e. with a custom comment syntax that you strip before interacting with external sources.
- hn_throwaway_99 6y ago
  I can't believe that anyone who has ever wanted to comment a package.json file could think Crockford's argument is anything but nonsense. The problem is these files are both edited by humans, and by a plethora of tools. Without a standard comment format, it's been a nightmare trying to comment package.json file in a way that doesn't break something in the NPM/Node ecosystem.
  - tshaddox 6y ago
    The fact that lots of people want to comment their package.json file and can’t easily due to Crockford’s decision does not mean that Crockford’s argument is nonsense. Crockford’s argument is not that there shouldn’t be comments in JSON because no one would want to use them. And again, I would also like to have comments in JSON.
    - hn_throwaway_99 6y ago
      My point is that I don't buy Crockford's argument, at all, against having comments in JSON. "I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability". So instead you have people coming up with a million different bad hacks to support comments in non standard ways (e.g. "fake comment" properties, duplicate keys, etc.) Coupled with the fact that since it's not in the standard, you never really know if the file you're creating may be read by something that won't strip comments. It's the worst of all possible worlds in my opinion, with 0 benefit.
      - tshaddox 6y ago
        I’ve personally never encountered any combination of JSON-encoded data and JSON parser that didn’t work perfectly together. I don’t know whether the right trade-offs were made between interoperability and other features, but I’d say it’s very clear that if interoperability was a chief design goal, it was executed extremely well.
        hn_throwaway_99 6y ago
- pseudalopex 6y ago
  You can expect JSON from external sources to be a JSON like notation their parser accepts. Not JSON always.
- coldtea 6y ago
  >But, since comments are not supported in JSON, you can expect JSON from external sources to contain no comments whatsoever. You can expect it, and then you'd be suprised when they do. See people really want/need comments, and they're gonna implement them anyway in dozens of little parsers/libs, and you're gonna have to deal with files having them anyway...
- BugsJustFindMe 6y ago
  > he didn’t want He didn't want. That's great, but using JSON doesn't magically eliminate the need for documenting what things _mean_. Oh, this text isn't just text and is actually a datestamp? Oh, this array isn't allowed to have repeat values? Oh, the valid values for this field are "red", "yellow", "purple", and 5? You could have had that documentation inline. Instead you're forced to have it somewhere else because the need for documentation didn't magically vanish when Crockford waved his wand. All that eliminating comments accomplishes is needlessly limiting the utility of an otherwise mostly fine format. JSON could have been a good configuration language. Instead it isn't and apparently people have to fight to justify fixing that.

ethanwillis 6y ago

If the rules are unspecified the only thing you wouldn't be able to put in comments are what is specified as JSON syntax. If you add minimal specifications for escape sequences then even that is allowed.

BugsJustFindMe 6y ago
> If you add specifications then Indeed.

tshaddox 6y ago

I wish JSON supported comments, but I don’t really understand your criticism. You say: > Without a standard format for comments, you have no reason whatsoever to expect the ad-hoc comments in a JSON file made by anyone who isn't you to be styled like JavaScript comments. But, since comments are not supported in JSON, you can expect JSON from external sources to contain no comments whatsoever. That’s precisely Crockford’s point: he didn’t want the format to have a comment syntax that works across different parties so that the only way to use comments is internally, i.e. with a custom comment syntax that you strip before interacting with external sources.

hn_throwaway_99 6y ago
I can't believe that anyone who has ever wanted to comment a package.json file could think Crockford's argument is anything but nonsense. The problem is these files are both edited by humans, and by a plethora of tools. Without a standard comment format, it's been a nightmare trying to comment package.json file in a way that doesn't break something in the NPM/Node ecosystem.
- tshaddox 6y ago
  The fact that lots of people want to comment their package.json file and can’t easily due to Crockford’s decision does not mean that Crockford’s argument is nonsense. Crockford’s argument is not that there shouldn’t be comments in JSON because no one would want to use them. And again, I would also like to have comments in JSON.
  - hn_throwaway_99 6y ago
    My point is that I don't buy Crockford's argument, at all, against having comments in JSON. "I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability". So instead you have people coming up with a million different bad hacks to support comments in non standard ways (e.g. "fake comment" properties, duplicate keys, etc.) Coupled with the fact that since it's not in the standard, you never really know if the file you're creating may be read by something that won't strip comments. It's the worst of all possible worlds in my opinion, with 0 benefit.
    - tshaddox 6y ago
      I’ve personally never encountered any combination of JSON-encoded data and JSON parser that didn’t work perfectly together. I don’t know whether the right trade-offs were made between interoperability and other features, but I’d say it’s very clear that if interoperability was a chief design goal, it was executed extremely well.
      - hn_throwaway_99 6y ago
pseudalopex 6y ago
You can expect JSON from external sources to be a JSON like notation their parser accepts. Not JSON always.
coldtea 6y ago
>But, since comments are not supported in JSON, you can expect JSON from external sources to contain no comments whatsoever. You can expect it, and then you'd be suprised when they do. See people really want/need comments, and they're gonna implement them anyway in dozens of little parsers/libs, and you're gonna have to deal with files having them anyway...
BugsJustFindMe 6y ago
> he didn’t want He didn't want. That's great, but using JSON doesn't magically eliminate the need for documenting what things _mean_. Oh, this text isn't just text and is actually a datestamp? Oh, this array isn't allowed to have repeat values? Oh, the valid values for this field are "red", "yellow", "purple", and 5? You could have had that documentation inline. Instead you're forced to have it somewhere else because the need for documentation didn't magically vanish when Crockford waved his wand. All that eliminating comments accomplishes is needlessly limiting the utility of an otherwise mostly fine format. JSON could have been a good configuration language. Instead it isn't and apparently people have to fight to justify fixing that.