Live data from Hacker News

Ignore the haters, and other lessons learned from creating JSON5

aseemk.substack.com

181–190 of 211 posts

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

#181

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…

So it's at best disingenuos or ignorant, merely not necessarily both.

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

#182

Earlier quoted context omitted.

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

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…

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.

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

#183
post #78

Let me give you a data point from a neutral perspective (I have never heard of you or JSON5). These were not haters. They in fact went our of their way to give arguments supporting their verdict, and in some cases even constructive suggestions like "make that a preprocessor instead". Your piece does not make you look like the smartest guy in the room, vindicated by success and adoring fans. It makes you look like som…

> I don't remember Mozart or Einstein lament about their haters.

Can't say for sure about Mozart, although I really would not put it past him to do so.

But here's Beethoven doing the same thing: https://quotepark.com/quotes/2122354-ludwig-van-beethoven-o-...

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

#184

Earlier quoted context omitted.

Right… and the fix is to switch from JSON to JSON5. I don’t see how assigning blame is productive here. People choose the wrong language, wrong library, or wrong tool all the time.

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

Under that argument, why bother improving anything?

At the end of the day, you can do anything you need to do in C.

What's the point of having all these other languages?

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

#185

Honestly I don't understand why JSON should be human-readable. It is a data serialization format intended to be read by software. Just adding comments and multi-line strings doesn't make it human-readable, it is still too bloated and I don't like writing it manually. If you want a human-readable format, try at least to remove unnecessary quotes, brackets and commas and make it look similar to YAML. JSON is not intend…

> JSON is not intended to be used in configs and other user-editable files. Yes, but it’s a bit late for that. It sounds like you’re advocating for a configuration format somewhere in the space between JSON and YAML. Not JSON, because it’s annoying to write by hand, no comments, no trailing commas. Not YAML, because of all those unintuitive edge cases like “no” (unquoted) being a Boolean. It sounds like the primary d…

See edn extensible data notation. https://github.com/edn-format/edn

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

#186

Looks great! Please add an unambiguous timestamp type :-)

If you get it added to javascript, then it will likely get added to JSON5 or a successor. Otherwise that's out of scope.

Javascript has a timestamp type, Date.

Of course what you mean is for javascript to have a timestamp literal. Well, the closest equivalent would be: `new Date("2021-12-17T03:24:00")`

It's cumbersome, but I would accept it:

    { mytimestamp: new Date("2021-12-17T03:24:00") }

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

#187

The only 2 things I'd like to add in JSON are trailing commas and comments, and this is already supported in most JSON configs (.eslintrc, .babelrc, ..), it's called JSONC I believe

.babelrc uses JSON5. ;)

https://github.com/babel/babel/blob/b1e73d6f961065c56427ffa8...

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

#188
post #132

Earlier quoted context omitted.

That's a terrible outlook. You are saying that all negative feedback should be ignored by everybody and treated as a positive sign. This is insane.

Nowhere, not once, did I say that all negative feedback should be ignored. I specifically stated "I have long held the belief that if the audience of Reddit or Twitter or Slashdot or Hackernews universally hates something with such vehemance that you doubt your own thoughts then you are probably doing the right thing." This is not "all negative feedback" or "that it should be ignored by everybody" or "treated as a po…

You could be getting hate with vehemence because you are doing something genuinely hurtful to society, or wrong, or illegal. You said that "if most of the audience [...] universally hates something, [...] you are probably doing the right thing". I restated it a little bit earlier, but surely you see how overly generic your statement is?

What is even the point of soliciting feedback if you will take a universally negative response as a positive?

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

#189
post #177

Earlier quoted context omitted.

Every lisp program supports that serialization format out of the box.

No, every lisp program supports its own idiosyncratic variation on it, no two alike.

Yes, just how no two json implementations support the same schema.

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

#190
post #177

Earlier quoted context omitted.

No, every lisp program supports its own idiosyncratic variation on it, no two alike.

Yes, just how no two json implementations support the same schema.

Independent JSON implementations can parse and manipulate the same files, since they agree on what the basic datatypes are. S-expression implementations don't; often they don't even agree on what the quoting convention is.
Post reply on HN