Ignore the haters, and other lessons learned from creating JSON5 • Hacker News Board

Re: Ignore the haters, and other lessons learned from creating JSON5

#201

Post by arinlen » Tue, Aug 09, 2022, 12:16 PM UTC

captainmuon wrote: post #199

arinlen wrote: post #162

Earlier quoted context omitted.

> Right… and the fix is to switch from JSON to JSON5. Not really. JSON offers no challenge in editing by hand. All comments I've seen in this thread boil down to people trying to pass off whimsical nice-to-haves as this sort of insurmountable problem. I mean, I do like a nice git history with small diffs. Not supporting trailing commas is unfortunate as it can cause the trailing line to show up in diffs if you add a…

> Let's be honest here: JSON5 solves no problem worth solving, at the expense of breaking compatibility. The problem I have is, I need a configuration language that is human readable, familiar to developers without teaching (anybody who knows JS, or to some extent Python and PHP), is also machine writable, and supports comments. The only language that supports this is JSON+comments (next contenders would be INI (!) a…

> The problem I have is, I need a configuration language that is human readable, familiar to developers without teaching (anybody who knows JS, or to some extent Python and PHP), is also machine writable, and supports comments.

I'd say if those were your criterias and you still stuck with a JSON-derived language, your decision-making process was a colossal failure in oversight, given the myriad of options around such as TOML or even YAML.

But let's pretend that adding comments and trailing commas to JSON makes any difference regarding those requirements.

Re: Ignore the haters, and other lessons learned from creating JSON5

#202

Post by arinlen » Tue, Aug 09, 2022, 5:26 PM UTC

claytongulick wrote: post #179

acedTrex wrote: post #178

Earlier quoted context omitted.

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

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 t…

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

Re: Ignore the haters, and other lessons learned from creating JSON5

#203

Post by shellfisher » Tue, Aug 09, 2022, 8:54 PM UTC

arinlen wrote: post #106

bobthepanda wrote: post #80

Earlier quoted context omitted.

This seems like making a mountain out of a molehill. > Extending the syntax is undoing all the communal work 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: https://gist.github.com/iddan/3d34b12f6b22c30a8a07c149b3175e... ). And ES5.1 itself was the product of communal work. > encroaching on gr…

> 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 p…

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.

Re: Ignore the haters, and other lessons learned from creating JSON5

#204

Post by lmm » Wed, Aug 10, 2022, 10:30 AM UTC

thrown_22 wrote: post #196

lmm wrote: post #195

Earlier quoted context omitted.

> That is not the job of the data format, that is the job of the meta data format. In theory maybe. In practice it's really nice that all JSON documents have the same standard handful of basic datatypes (number, string, etc.). > Again, json is gods way of teaching bad devs why xml is such a mess. Maybe that's the lesson bad devs take from it. Good devs take something rather different from it.

>In theory maybe. In practice it's really nice that all JSON documents have the same standard handful of basic datatypes (number, string, etc.). You missed boolean. That's it. Those are the supported types by json. But tell me more about how you can guess the type of 1515151515151 without context. >Maybe that's the lesson bad devs take from it. Good devs take something rather different from it. Thank you, people like…

> But tell me more about how you can guess the type of 1515151515151 without context.

In JSON if that's an expression then it's a number. You're the one advocating S-expressions, which is where you'd have to guess the type, so tell me how you'd figure the type out there. Heck, you're complaining about the fact that JSON schema is only a draft, but that's still decades ahead of the state of standardised S-expression formats.

> Thank you, people like you are the reason why I can quit my job and any time and find another one paying mid six figures to fix your messes.

Right back at you lol.

Re: Ignore the haters, and other lessons learned from creating JSON5

#205

Post by captainmuon » Thu, Aug 11, 2022, 6:15 AM UTC

arinlen wrote: post #201

captainmuon wrote: post #199

Earlier quoted context omitted.

> Let's be honest here: JSON5 solves no problem worth solving, at the expense of breaking compatibility. The problem I have is, I need a configuration language that is human readable, familiar to developers without teaching (anybody who knows JS, or to some extent Python and PHP), is also machine writable, and supports comments. The only language that supports this is JSON+comments (next contenders would be INI (!) a…

> The problem I have is, I need a configuration language that is human readable, familiar to developers without teaching (anybody who knows JS, or to some extent Python and PHP), is also machine writable, and supports comments. I'd say if those were your criterias and you still stuck with a JSON-derived language, your decision-making process was a colossal failure in oversight, given the myriad of options around such…

TOML is basically INI. It adds nested sections, but it is not so obvious how to use them. And the data model is more complicated, with sections first, and in each section a key-value map.

YAML has a data model like JSON, but it is disqualified for me by the syntax ambiguities.

The easiest thing is if people could just write JS (or Python) object literals, but restricted to plain old data, and without the ability to call functions etc.. JSON5 gives exactly that.

Re: Ignore the haters, and other lessons learned from creating JSON5

#206

Post by xpe » Thu, Aug 11, 2022, 12:17 PM UTC

arinlen wrote: post #202

claytongulick wrote: post #179

Earlier quoted context omitted.

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 t…

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

The commenters above (who I agree with) are suggesting the following, I think:

Rather than write this:

> This take is disingenuous and horribly uninformed and very shortsighted.

Write this instead: "This take is horribly uninformed and very shortsighted."

Think of this way: we're asking if you can find ways to not assume bad faith in another party.

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

From the Apple dictionary:

>> disingenuous: not candid or sincere, typically by pretending that one knows less about something than one really does: he was being somewhat disingenuous as well as cynical.

Re: Ignore the haters, and other lessons learned from creating JSON5

#207

Post by RobertWHurst » Thu, Aug 11, 2022, 4:40 PM UTC

arinlen wrote: post #106

bobthepanda wrote: post #80

Earlier quoted context omitted.

This seems like making a mountain out of a molehill. > Extending the syntax is undoing all the communal work 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: https://gist.github.com/iddan/3d34b12f6b22c30a8a07c149b3175e... ). And ES5.1 itself was the product of communal work. > encroaching on gr…

> 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 p…

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.

Re: Ignore the haters, and other lessons learned from creating JSON5

#208

Post by RobertWHurst » Thu, Aug 11, 2022, 4:47 PM UTC

arinlen wrote: post #111

gervwyk wrote: post #15

I enjoy using json5. I solves a real problem imo.. Regarding the criticism, I get the same bad energy when people get a kick out of fixing someone’s grammar, and then do not even comprehend what is being complicated. Well done on the lib and thanks for building something useful! Good writeup also! Think I’m going to give the commit access trick a shot.

> I enjoy using json5. I solves a real problem imo.. And what problem would that be?

If you don't know then why are you commenting? Go read the Readme, and stop talking smack about other people's projects when you don't know such basic details.

Re: Ignore the haters, and other lessons learned from creating JSON5

#209

Post by chris_wot » Fri, Aug 12, 2022, 5:58 AM UTC

pvg wrote: post #148

chris_wot wrote: post #130

Earlier quoted context omitted.

Actually, I found this enlightening. It didn’t reduce the signal to noise ratio in any way.

The comment would have been no less enlightening if just linked. Additionally, this whole thing is just made of pure noise - someone's taking some sort of bizarre victory lap over some slight they feel HN inflicted upon them... 10 years ago.

I’ve thought about it, and you are probably mostly roght, though I don’t think the poster was trying to take a “victory lap around anyone.

Re: Ignore the haters, and other lessons learned from creating JSON5

#210

Post by beej71 » Wed, Aug 17, 2022, 3:18 PM UTC

leaflets2 wrote: post #170

beej71 wrote: post #159

I'll take any feedback. If someone tells me I'm dumb and have it wrong, I thank them and fix it. Now they can't complain about it, I learned something, and someone spent their time giving me free advice. But if they don't convince me I'm wrong, then I ignore them. :)

> But if they don't convince me I'm wrong, then I ignore them What if, though, they convince others that you're wrong -- so no one wants to use your software? (although it would have been helpful to many)

(Sorry for the late reply.)

I can post my counterarguments and then the other folks can decide. If the argument is compelling and cogent, people listen.

But I know I'll never convince everyone to like my stuff. The goal is to make a quality, useful product while listening to good suggestions for improvement and not letting people get you down.