4 ms·

> JSON5 takes stuff from ES5.1 and adds it to JSON, and ES5 is backwards-compatible with older JS. This means it's fairly trivial to convert JSON5 to JSON (lite

> JSON5 takes stuff from ES5.1 and adds it to JSON, and ES5 is backwards-compatible with older JS. This means it's fairly trivial to convert JSON5 to JSON (literally 13 lines). This take is disingenuous and horribly uninformed and very shortsighted. Not every parser out there is JavaScript eval(). Some people actually had to write and maintain a parser in whatever programming language they have to work with. In the past I wrote a JSON parser for a low-level language, and back then I had to write the letter and parser by hand. Each change to accepted JSON values meant I had to add at least one terminal token, update the grammar to include it, and update the data model to support yet another type. Adding comments would either require adding a terminal token to be ignored, or rewrite the data model to support positional items that cursors/iterators could or could not skip. These are not 13LoC changes. At all. And if I happen to be consuming an API I don't control which for God knows what reason decided to move to json5, I would either have to rush a parser to production or remain down.

h0l0cube 4y ago
I agree with your point here (but I'm not the GP). The main thrust of the article is about finding product/market fit, and it could be said here that the market isn't the parser writers, who would be disrupted, but the developers who want a JSON format with better ergonomics. > And if I happen to be consuming an API I don't control which for God knows what reason decided to move to json5 And such a decision might be the API maintainers not understanding their users.
- Brian_K_White 4y ago
  It's no longer better ergonomics if you can't use it at all because half your endpoints don't support it, and the reason they don't support it is not mere neutral time or popularity but a result of the fact that the new form no longer posesses the qualities that made the original form useful. This really does look like a case of missing a point and proceeding with a bad idea that results in an all around increase in harm, because no matter the idea, there will always be at least a few adopters and then everyone else has to deal with it. If it's allowed for anyone to come up with any new idea they want, then it has to be equally allowed for others to criticize. Anything else is literally not sane. It's perfectly likely the "haters" are right and the idea is bad and should not be adopted or proliferate. It's also possible they are merely unthinking haters. But calling them "haters" is not a valid defense of the idea.
  - h0l0cube 4y ago
    > If it's allowed for anyone to come up with any new idea they want, then it has to be equally allowed for others to criticize. Never disputed this. > It's no longer better ergonomics if you can't use it at all because half your endpoints don't support it Incompatibility != lack of ergonomics. People use new and incompatible frameworks all the time. It could be argued that JSON had better ergonomics at a time when XML was more popular, in spite of impedance mismatch with other APIs. Similar could be said of what's happening with python 3 vs python 2 the last decade. How do standards improve without breaking anything? > But calling them "haters" is not a valid defense of the idea. From reading the article, it seems like people were particularly cruel, well beyond constructive criticism into straight up ridicule: > But he went even further: Mitchell took the time to make a parody project of JSON5 [..] even making fun of me by name. OP was gracious about it however: > I reached out to Mitchell as part of writing this post [..] I assumed he regretted it in retrospect, and I harbored no grudge or ill will towards him. > Mitchell confirmed this assumption to be true and offered a genuine, sincere apology. Thank you, Mitchell — I appreciated that a lot. He doesn't appear to take personal affront, so I think his use of the term 'haters' is playful, but I think also fair when you consider that even those mocking them felt bad about their conduct.
dietrichepp 4y ago
Saying the take is “disingenuous” is certainly a rude and inappropriate response. You can disagree with someone without accusing them of being insincere or arguing in bad faith (which is what “disingenuous” means).
- acedTrex 4y ago
  It is disingenuous to reply to a comment about "undoing all the json parser work across multiple languages" with "no it hasn't it's just 13 lines in javascript see!"
  - claytongulick 4y ago
    It is potentially uninformed, possibly mistaken, but not disingenuous. We're supposed to assume best intent. Accusing someone of being "disingenuous", "horribly uninformed" and "short sighted" for providing an different opinion isn't doing that. I learned something from the post. I learned that these enhancements are already mostly being codified in the language. That influenced my opinion on the subject. I assumed that the 13 lines of code comment was in the context of js, not (for example) a c parser, where it's pretty normal for 13 lines of js to translate to hundreds or potentially thousands of lines of C code. The post was informative and respectful. The name-calling response was not.
    - Brian_K_White 4y ago
      So it's at best disingenuos or ignorant, merely not necessarily both.
    - arinlen 4y ago
      > We're supposed to assume best intent. No one with the faintest understanding of what a parser is and does would ever claim that any of these changes could ever take 13loc to implement. If they are ignorant and still feel compelled to pass false claims on how significant changes are instead trivial just to try to downplay the real world challenges, they are undoubtedly being disingenuous.
shellfisher 4y ago
If you happened to use an API that switched to XML or whatever other thing you’d be in the same boat. What a ridiculous argument.
RobertWHurst 4y ago
Comments is clearly for configs, not for server responses, but even if someone did respond with json5, as the previous post said, you don't have to tokenize the json5, you can convert it to json first (since I would imagine you don't need comments). I can imagine how you feel about graphql.

h0l0cube 4y ago

I agree with your point here (but I'm not the GP). The main thrust of the article is about finding product/market fit, and it could be said here that the market isn't the parser writers, who would be disrupted, but the developers who want a JSON format with better ergonomics. > And if I happen to be consuming an API I don't control which for God knows what reason decided to move to json5 And such a decision might be the API maintainers not understanding their users.

Brian_K_White 4y ago
It's no longer better ergonomics if you can't use it at all because half your endpoints don't support it, and the reason they don't support it is not mere neutral time or popularity but a result of the fact that the new form no longer posesses the qualities that made the original form useful. This really does look like a case of missing a point and proceeding with a bad idea that results in an all around increase in harm, because no matter the idea, there will always be at least a few adopters and then everyone else has to deal with it. If it's allowed for anyone to come up with any new idea they want, then it has to be equally allowed for others to criticize. Anything else is literally not sane. It's perfectly likely the "haters" are right and the idea is bad and should not be adopted or proliferate. It's also possible they are merely unthinking haters. But calling them "haters" is not a valid defense of the idea.
- h0l0cube 4y ago
  > If it's allowed for anyone to come up with any new idea they want, then it has to be equally allowed for others to criticize. Never disputed this. > It's no longer better ergonomics if you can't use it at all because half your endpoints don't support it Incompatibility != lack of ergonomics. People use new and incompatible frameworks all the time. It could be argued that JSON had better ergonomics at a time when XML was more popular, in spite of impedance mismatch with other APIs. Similar could be said of what's happening with python 3 vs python 2 the last decade. How do standards improve without breaking anything? > But calling them "haters" is not a valid defense of the idea. From reading the article, it seems like people were particularly cruel, well beyond constructive criticism into straight up ridicule: > But he went even further: Mitchell took the time to make a parody project of JSON5 [..] even making fun of me by name. OP was gracious about it however: > I reached out to Mitchell as part of writing this post [..] I assumed he regretted it in retrospect, and I harbored no grudge or ill will towards him. > Mitchell confirmed this assumption to be true and offered a genuine, sincere apology. Thank you, Mitchell — I appreciated that a lot. He doesn't appear to take personal affront, so I think his use of the term 'haters' is playful, but I think also fair when you consider that even those mocking them felt bad about their conduct.

dietrichepp 4y ago

Saying the take is “disingenuous” is certainly a rude and inappropriate response. You can disagree with someone without accusing them of being insincere or arguing in bad faith (which is what “disingenuous” means).

acedTrex 4y ago
It is disingenuous to reply to a comment about "undoing all the json parser work across multiple languages" with "no it hasn't it's just 13 lines in javascript see!"
- claytongulick 4y ago
  It is potentially uninformed, possibly mistaken, but not disingenuous. We're supposed to assume best intent. Accusing someone of being "disingenuous", "horribly uninformed" and "short sighted" for providing an different opinion isn't doing that. I learned something from the post. I learned that these enhancements are already mostly being codified in the language. That influenced my opinion on the subject. I assumed that the 13 lines of code comment was in the context of js, not (for example) a c parser, where it's pretty normal for 13 lines of js to translate to hundreds or potentially thousands of lines of C code. The post was informative and respectful. The name-calling response was not.
  - Brian_K_White 4y ago
    So it's at best disingenuos or ignorant, merely not necessarily both.
  - arinlen 4y ago
    > We're supposed to assume best intent. No one with the faintest understanding of what a parser is and does would ever claim that any of these changes could ever take 13loc to implement. If they are ignorant and still feel compelled to pass false claims on how significant changes are instead trivial just to try to downplay the real world challenges, they are undoubtedly being disingenuous.

shellfisher 4y ago

If you happened to use an API that switched to XML or whatever other thing you’d be in the same boat. What a ridiculous argument.

RobertWHurst 4y ago

Comments is clearly for configs, not for server responses, but even if someone did respond with json5, as the previous post said, you don't have to tokenize the json5, you can convert it to json first (since I would imagine you don't need comments). I can imagine how you feel about graphql.