Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ignore the haters, and other lessons learned from creating JSON5

aseemk.substack.com

Post reply on HN
Print view View original

101–110 of 211 posts

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

#101

Post by XorNot »

kryptiskt wrote: post #36
codedokode wrote: post #16

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…

The first two sentences of the text on http://json.org are "JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write." It's a primary goal of JSON, it's fair to question whether it's successful at it. Personally, I'd much rather write TOML or S expressions. I don't like YAML at all, the whitespace sensitivity drives me nuts.

I don't get how anyone uses TOML. YAML is whitespace sensitive but it's python rules and quite sensible.

TOML is just plain unreadable to me when I have to figure out what I'm looking at: I convert it to YAML to both read and write it when I have to add new lists/maps.

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

#102

Post by [deleted] »

AndriyKunitsyn wrote: post #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 y…

[deleted]

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

#103

Post by jhardy54 »

bobthepanda wrote: post #80
vlunkr wrote: post #49

Earlier quoted context omitted.

Many of those original comments were pretty spot on though. Maybe the constructive criticism you need sometimes is “don’t do this” JSON is useful partially because it’s easy to parse, so parsers already exist in every language. Extending the syntax is undoing all the communal work, and encroaching on grounds that YAML and other languages already cover.

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…

> This means it's fairly trivial to convert JSON5 to JSON (literally 13 lines: https://gist.github.com/iddan/3d34b12f6b22c30a8a07c149b3175e...).

Did you paste the correct link? This just plumbs together an existing JSON 5 parser with a JSON 4 serializer.

How many lines does this take without importing a library the solves this for you?

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

#104

Post by chris_wot »

AnimalMuppet wrote: post #73
TylerE wrote: post #47

Earlier quoted context omitted.

Shockingly about 98% of the population doesn't find massive mounds of nested parens especially readable.

But massive mounds of is readable? I mean, I guess you know what each tag is closing, which is more than you get with ))))...

It kind of is, actually.

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

#105

Post by mikkergp »

wildwildtest wrote: post #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.…

Except Mitchell explicitly called the author out in his satire and the author was right that Mitchell thought in retrospect it was a mistake to do so. Why is it in poor character if he’s expressing a view Mitchell agrees with.

Additionally in terms of the criticism, I observe the inverse phenomena to what you describe. You say that popularity isn’t a good indicator of goodness, but I think the inverse is goodness isn’t an indicator of eventual popularity. Some very elegant solutions just aren’t flexible enough for the real world. It is short sighted to try to argue some objective definition of badness because it doesn’t solve a problem you have or doesn’t fit your version of what a product like that should be. Sometimes in the absence of perfection people just have to get work done and want tools that make that easier.

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

#106

Post by arinlen »

bobthepanda wrote: post #80
vlunkr wrote: post #49

Earlier quoted context omitted.

Many of those original comments were pretty spot on though. Maybe the constructive criticism you need sometimes is “don’t do this” JSON is useful partially because it’s easy to parse, so parsers already exist in every language. Extending the syntax is undoing all the communal work, and encroaching on grounds that YAML and other languages already cover.

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

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

#107

Post by chris_wot »

moonchrome wrote: post #61
bogota wrote: post #50

Earlier quoted context omitted.

This is a great example of how argument by analogy completely breaks down and just helps the author express their feelings. But for a second it makes them feel smart.

Maybe expressing feelings about the topic, as a guess behind the motivation for the mocking repo, was my intention ? (like I said in the second part of the post) Left-pad shitshow showed how relevant NPM dependency chain is as a measure of quality and what it does for the ecosystem. This is left-pad with added complexity to sneak in malicious code.

Why do you feel it will sneak in malicious code?

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

#108

Post by mikepurvis »

11235813213455 wrote: post #17

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

A native set type would be nice too, and the syntax for it is obvious— comma separated values like a list, but enclosed in braces like a dict.

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

#109

Post by livinginfear »

hnusersarelame wrote: post #3

The kind of people who leave criticism on HN are not worth listening to anyway. Most of the users of this site have no taste and think they're more brilliant / important than they actually are.

> ...not worth listening to anyway...

> ...Most of the users of this site...

> ...think they're more brilliant...

I suppose the above critiques are not directed at yourself?

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

#110

Post by inopinatus »

kryptiskt wrote: post #36
codedokode wrote: post #16

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…

The first two sentences of the text on http://json.org are "JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write." It's a primary goal of JSON, it's fair to question whether it's successful at it. Personally, I'd much rather write TOML or S expressions. I don't like YAML at all, the whitespace sensitivity drives me nuts.

Douglas Crockford usually says he discovered JSON, and subsequently named it and wrote a specification, and I think this precludes suggesting it had design goals, because it wasn't an invention. More broadly, I also think this understanding of JSON's origins absolves the discoverers of its limitations, and opens the door to talking about improvements and variations.

Notwithstanding which, I too would prefer to interchange data via S-expressions.

Post reply on HN