13 ms·

> The only thing that JSON is really missing are comments and trailing commas. The reason JSON doesn't have comments [1]: I removed comments from JSON bec

> The only thing that JSON is really missing are comments and trailing commas. The reason JSON doesn't have comments [1]: I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. 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. [1] http://archive.today/8FWsA http://archive.today/8FWsA

SV_BubbleTime 2y ago
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.
- KPGv2 2y ago
  > the larger issue is an inventor kneecapping something by stating how you should use it This isn't kneecapping something any more than an inventor requiring programmers in a new language use types, or not use types, whichever the inventor deems preferable. He invented a thing. He declared how the thing is constructed. That's not kneecapping. That's just defining a thing.
  - Brian_K_White 2y ago
    It is kneecapped. He invented a thing and left out a well known and understood core function required in the problem space, deliberately, not through oversight. That's what makes it kneecapping. The whole useful thing, ie the idea of a data format, including both knees (ie all the basic features any such thing needs) was there. The concept and necessity of annotation was a well known thing by then, and indeed he knew of it himself too, said so himself, and actively removed one functioning knee from that whole, to produce only the kneecapped thing. He defined a kneecapped thing. Or he kneecapped the design. Whichever way you want to say it. The difference would be if it was 40 years earlier and you are taking the fist stab at designing any kind of data format and comments just never occurred to you yet. This is more like making a new programming language and deciding that it shall not have one of the basic math operators. If you need to multiply, tough shit, do it some other way. Just pipe it through JSMulti.
    - gazook89 2y ago
      But he designed it with intention, as stated. It wasn’t like “ha ha suckers, no comments for you!” He just didn’t think it was a good idea and had a reason for it. Are inventors required to only innovate a little bit? He released it, and there was every opportunity for someone else to offer something better and achieve the same level of uptake.
hn_throwaway_99 2y ago
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.
- mp05 2y ago
  @fat is that you?
  - hn_throwaway_99 2y ago
    Did you just call me fat ;) I don't know who @fat is, but if he thinks Crockford's rationalization for the lack of comments in JSON is total and complete BS, I like the way he thinks.
    - mp05 2y ago
eviks 2y ago
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
- Brian_K_White 2y ago
  This. You can make special key names that are really directions for something. You can make enrire k v pairs that are never used by anything that actually parses the json normally. Argument was invalid as far as I can see and calling it "sorry it makes you sad" is, wow I don't even know where to begin with that. Having annotation happen in a dedicated place designed for it is better than having it happen where it was not designed to be, end of math problem.
  - throwaway290 2y ago
    You are saying as if there was an apology or it should be needed for some reason. For any spec there are people who want something spec doesn't do and people writing the spec need to say no to requests that they consider not in scope as much or more often than they say yes
    - Brian_K_White 2y ago
      There was literally an apology, a douchebag backhanded false one, but still acknowledged explicitly that there was a thing he knew everyone would want, and knew it would "make some people sad". Comments are not some weird thing one person wants for their weird reason that no one else needs to care about. It's like leaving out a letter from the alphabet.
      - throwaway290 2y ago
        One wants comments, another wants single quotes, third wants ... Just acknowledging someone wants something out of scope is not an apology
nurettin 2y ago
We should call this "The Crockford Fallacy". Destroying something valuable in fear of a perceived threat.
- AnthonBerg 2y ago
  We should preemptively destroy the concept of the Crockford Fallacy because people might seek to emulate it, right?
  - nurettin 2y ago
    You can destroy the concept, but people will reconstruct it from the ironic remains.
fuzzythinker 2y ago
That's a terrible reasoning for requiring an extra toolchain.
hansvm 2y ago
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.
Zamicol 2y ago
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."
naikrovek 2y ago
> 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.
gregoriol 2y ago
So instead of comments with parsing directives, people use underscore prefixed keys to keep metadata and comments, that's not a win at all
- motorest 2y ago
  > So instead of comments with parsing directives, people use underscore prefixed keys to keep metadata and comments, that's not a win at all Your comment doesn't make any sense. You're just pointing out that developers designed data interchange formats as subsets of JSON which explicitly support metadata and comments. This means they are specifying their schemas to support these usecases in a way clients can and do support it. That, if anything, proves right the decision to not support comments because it resulted in better-defined and well-behaving clients.
  - gregoriol 2y ago
    Comments could be skipped by parsers, instead parsers need to parse and store those keys/values that are not relevant. This is not called efficient.
- arp242 2y ago
  The thing is that JSON was intended to be a data exchange format, not a configuration file format or anything else. IMHO Crockford's reasoning makes a lot more sense with that in mind.
  - JambalayaJimbo 2y ago
    Data interchange formats are often used for configuration. It makes sense to have a single source of truth in json if your configuration is consumed by an app.
  - gregoriol 2y ago
    Even if we stick to the data exchange format, it would be practical to have comments in examples of data. This would be good for training and learning, for documentation.
adamc 2y ago
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.
- hn_throwaway_99 2y ago
  I agree, engineering is all a series of tradeoffs, and tradeoffs can go one way or the other. That said, I have yet to see anyone ever say "Oh man, this programming/configuration/data transfer language would be so great, but I wish they hadn't supported comments!" I see the opposite about JSON all the time. And I don't see this about other features, e.g. Go specifically decided not to support the ternary operator, and while some folks may like that feature, I think more folks really appreciate that with Go there is generally a "standard" way to do things and it doesn't give you a million different ways to essentially do the same thing.
pbreit 2y ago
It might be abused and you can just pipe it through a preprocessor are not very good reasons.
thwarted 2y ago
Abuse of comments is not an academic, theoretical consideration. https://www2.jwz.org/doc/cddb.html 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)

SV_BubbleTime 2y ago

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.

KPGv2 2y ago
> the larger issue is an inventor kneecapping something by stating how you should use it This isn't kneecapping something any more than an inventor requiring programmers in a new language use types, or not use types, whichever the inventor deems preferable. He invented a thing. He declared how the thing is constructed. That's not kneecapping. That's just defining a thing.
- Brian_K_White 2y ago
  It is kneecapped. He invented a thing and left out a well known and understood core function required in the problem space, deliberately, not through oversight. That's what makes it kneecapping. The whole useful thing, ie the idea of a data format, including both knees (ie all the basic features any such thing needs) was there. The concept and necessity of annotation was a well known thing by then, and indeed he knew of it himself too, said so himself, and actively removed one functioning knee from that whole, to produce only the kneecapped thing. He defined a kneecapped thing. Or he kneecapped the design. Whichever way you want to say it. The difference would be if it was 40 years earlier and you are taking the fist stab at designing any kind of data format and comments just never occurred to you yet. This is more like making a new programming language and deciding that it shall not have one of the basic math operators. If you need to multiply, tough shit, do it some other way. Just pipe it through JSMulti.
  - gazook89 2y ago
    But he designed it with intention, as stated. It wasn’t like “ha ha suckers, no comments for you!” He just didn’t think it was a good idea and had a reason for it. Are inventors required to only innovate a little bit? He released it, and there was every opportunity for someone else to offer something better and achieve the same level of uptake.

hn_throwaway_99 2y ago

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.

mp05 2y ago
@fat is that you?
- hn_throwaway_99 2y ago
  Did you just call me fat ;) I don't know who @fat is, but if he thinks Crockford's rationalization for the lack of comments in JSON is total and complete BS, I like the way he thinks.
  - mp05 2y ago

eviks 2y ago

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

Brian_K_White 2y ago
This. You can make special key names that are really directions for something. You can make enrire k v pairs that are never used by anything that actually parses the json normally. Argument was invalid as far as I can see and calling it "sorry it makes you sad" is, wow I don't even know where to begin with that. Having annotation happen in a dedicated place designed for it is better than having it happen where it was not designed to be, end of math problem.
- throwaway290 2y ago
  You are saying as if there was an apology or it should be needed for some reason. For any spec there are people who want something spec doesn't do and people writing the spec need to say no to requests that they consider not in scope as much or more often than they say yes
  - Brian_K_White 2y ago
    There was literally an apology, a douchebag backhanded false one, but still acknowledged explicitly that there was a thing he knew everyone would want, and knew it would "make some people sad". Comments are not some weird thing one person wants for their weird reason that no one else needs to care about. It's like leaving out a letter from the alphabet.
    - throwaway290 2y ago
      One wants comments, another wants single quotes, third wants ... Just acknowledging someone wants something out of scope is not an apology

nurettin 2y ago

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

AnthonBerg 2y ago
We should preemptively destroy the concept of the Crockford Fallacy because people might seek to emulate it, right?
- nurettin 2y ago
  You can destroy the concept, but people will reconstruct it from the ironic remains.

fuzzythinker 2y ago

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

hansvm 2y ago

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.

Zamicol 2y ago

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

naikrovek 2y ago

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

gregoriol 2y ago

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

motorest 2y ago
> So instead of comments with parsing directives, people use underscore prefixed keys to keep metadata and comments, that's not a win at all Your comment doesn't make any sense. You're just pointing out that developers designed data interchange formats as subsets of JSON which explicitly support metadata and comments. This means they are specifying their schemas to support these usecases in a way clients can and do support it. That, if anything, proves right the decision to not support comments because it resulted in better-defined and well-behaving clients.
- gregoriol 2y ago
  Comments could be skipped by parsers, instead parsers need to parse and store those keys/values that are not relevant. This is not called efficient.
arp242 2y ago
The thing is that JSON was intended to be a data exchange format, not a configuration file format or anything else. IMHO Crockford's reasoning makes a lot more sense with that in mind.
- JambalayaJimbo 2y ago
  Data interchange formats are often used for configuration. It makes sense to have a single source of truth in json if your configuration is consumed by an app.
- gregoriol 2y ago
  Even if we stick to the data exchange format, it would be practical to have comments in examples of data. This would be good for training and learning, for documentation.

adamc 2y ago

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.

hn_throwaway_99 2y ago
I agree, engineering is all a series of tradeoffs, and tradeoffs can go one way or the other. That said, I have yet to see anyone ever say "Oh man, this programming/configuration/data transfer language would be so great, but I wish they hadn't supported comments!" I see the opposite about JSON all the time. And I don't see this about other features, e.g. Go specifically decided not to support the ternary operator, and while some folks may like that feature, I think more folks really appreciate that with Go there is generally a "standard" way to do things and it doesn't give you a million different ways to essentially do the same thing.

pbreit 2y ago

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

thwarted 2y ago

Abuse of comments is not an academic, theoretical consideration. https://www2.jwz.org/doc/cddb.html 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)