Live data from Hacker News

Ignore the haters, and other lessons learned from creating JSON5

aseemk.substack.com

81–90 of 211 posts

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

#81
post #33

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…

I read and write json manually almost every day. I haven't bothered to insert json5 in our pipelines for various reasons, but I sure wish it was the default. The interesting question I think is, why do you think json is so used in that capacity despite not being meant for it? Why YAML, despite being so widespread, hasn't swept json away for those purposes? (let's for a moment ignore that YAML can go REALLY nuts, and…

> let's for a moment ignore that YAML can go REALLY nuts, and think only of the simplest version of it

But we can't ignore it… we have to validate and make sure it isn't going too nuts. And we will probably fail at that.

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

#82
post #13

Does ‘downloads per day’ actually mean anything? It could be someone large company’s CI system building on every commit. I don’t think I’ve ever seen a JSON5 file in the wild. I’ve always wanted comments in JSON, but the other issues highlighted are not things I care about. The ‘be lenient in what you accept’ philosophy is a disaster, just look at HTTP… stricter is better IMO.

Does ‘downloads per day’ actually mean anything? It could be someone large company’s CI system building on every commit. I don't think you understand quite how many 60,000,000 downloads per week is if you think a big company's CI pipeline might account for that.

Maybe 2 or 3 big companies.

I'll never understand why those companies can't bother to set up an internal mirror.

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

#83

Does ‘downloads per day’ actually mean anything? It could be someone large company’s CI system building on every commit. I don’t think I’ve ever seen a JSON5 file in the wild. I’ve always wanted comments in JSON, but the other issues highlighted are not things I care about. The ‘be lenient in what you accept’ philosophy is a disaster, just look at HTTP… stricter is better IMO.

CI like that can give you some boost, but if the project is building many times a day, the dependencies are cached somewhere. Otherwise people get too annoyed with delays. There may be a phase of lots of downloads, but then it gets fixed.

I think most companies do not set up mirrors. There is no way millions of individual companies are downloading daily the same pieces of code. And if they had caching they'd download them only when a new release happens, not daily.

There aren't that many companies in the world basically.

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

#84

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…

Programmer readable, not user readable. It's far easier to learn what it means by just looking at an example than by reading some abstract documentation as you would have to with binary data or some home-made format.

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

#85
Phew, when I read these posts, I often wonder if I said something dumb in the past and I think I can easily be proud of my comments there, though I missed the JSON5 thing[0]. Fortunately, the thing that keeps me from saying dumb shit about other peoples' tech is:

* my belief that people who execute on some project are inherently superior - they made a thing to solve a problem! Automatically superior to people who didn't make a thing

* the Blub Paradox http://paulgraham.com/avg.html I can only judge projects accurately where I am operating at a higher-level of thought. If I don't get the need, then I am probably not operating at a higher-level than the author. I prefer to be able to have sufficient Theory of Mind thinking that I can inhabit the author's mind to see why they need something, make the best case for it, and then reject/accept it if I have to. There are many places where I can't. The most trivial example which everyone grasped before I got there is GraphQL as an API specification and IDL, which I only recently really grokked.

In any case, I had a figment of the idea that you talk about which is the "people who won't be your users". Thanks for citing the thought around that.

Congrats and good luck!

0: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

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

#86
I think the real lesson is that popularity is a poor way of understanding whether something is actually useful or good, it can indicate those qualities but meaningless without also applying our reasoning faculties too. The author appears to remain oblivious to any of the very good reasons why people don’t like alternative json formats and incapable of incorporating that into their understanding of people’s reaction. Citing market mechanics as a justification of “popularity = value” is blowing past the many examples of where free markets produce terrible approximations of value.

Also, I think it’s very poor character to say on one hand that people’s reaction doesn’t bother them and dedicate a third to a half of the article to Mitchell’s criticism specifically. I think Mitchell’s criticism is completely reasonable (I remember this as an era of “solving json” through multiple alternative formats) and drawing attention to what seems in retrospect as a mean-spirited act is actually quite a cynical attempt to strip the context of it and deliberately cast Mitchell in a poor light. Mitchell’s intention is very clearly a technically minded one to nudge people away from trying to massage long term, durable standards in often trivial, subjective ways with an end goal that can only result in format thrashing that doesn’t ever address anything substantial.

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

#88
In videogames, "If there are enemies ahead of you, then you are going the right now."

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.

In the words of Casey Neistat, in his video "Do what you can't." - "To the haters, the doubters, my 7th grade vice principal, to everyoneone who has ever anyone with a dream they can't..."

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

#89
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 wrote a python library.

Someone online told me another library (released after mine) was doing the same thing.

Turns out other library has very obvious bugs, is 20x times slower, but it has 8x more downloads.

Yep downloads are not a metric of quality.

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

#90
I'm really puzzled by "JSON is for machines, not for humans" types of comments here. FFS, JSON has whitespaces, that alone should answer who it was made for. And making human-readable formats more human-readable is a good thing. JSON5 is awesome.

If the performance of your module suffers from parsing its inputs, you are doing some Really Terrible Thing with your inputs. And if the nature of the task really requires you to parse data quickly and on a big scale, it would be better to ditch JSON altogether and switch to a binary format like protobuf instead.

Post reply on HN