Live data from Hacker News

Ignore the haters, and other lessons learned from creating JSON5

aseemk.substack.com

191–200 of 211 posts

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

#191
post #190

Earlier quoted context omitted.

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.

>since they agree on what the basic datatypes are

That is not the job of the data format, that is the job of the meta data format. That this is still a draft tells you how far behind json is: https://json-schema.org/draft/2020-12/json-schema-core.html

Again, json is gods way of teaching bad devs why xml is such a mess.

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

#192

On the other side of this, it's fascinating how often people fall susceptible to arguing why something should or shouldn't exist for someone else, rather than just making a limited statement about utility for themselves. Something to stay cognizant of, this article is a good lesson on empathy!

Not everything is about yourself. And once everyone is using some terrible format you won't be able to avoid it anyway.

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

#193

Earlier quoted context omitted.

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

He made changes that were based on design goals. He simplified a few parts, and removed comments with the explicitly stated goal of avoiding parsing directives. We can say the underlying idea of taking javascript's object syntax was a discovery, but he refined it between discovery and release.

This seems to merely be applying Saint-Exupéry's rule as an editor, which is a matter of baseline competence, and hardly seems worthy of description as a goal of any sort.

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

#194

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…

Yaml is kind of readable, but god help you if you have to write it

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

#195
post #190

Earlier quoted context omitted.

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.

>since they agree on what the basic datatypes are That is not the job of the data format, that is the job of the meta data format. That this is still a draft tells you how far behind json is: https://json-schema.org/draft/2020-12/json-schema-core.html Again, json is gods way of teaching bad devs why xml is such a mess.

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

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

#196
post #195

Earlier quoted context omitted.

>since they agree on what the basic datatypes are That is not the job of the data format, that is the job of the meta data format. That this is still a draft tells you how far behind json is: https://json-schema.org/draft/2020-12/json-schema-core.html Again, json is gods way of teaching bad devs why xml is such a mess.

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

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

#197

Earlier quoted context omitted.

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…

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

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

#198

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

To each their own, but I find mandatory quoted keys a pain in the ass, and once you change those three things you're basically at JSON5.

I kind of wish Apple hadn't deprecated NeXT-style property lists and had instead gone in the direction of GNUstep by trying to improve the classic format.

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

#199

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…

> 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 (!) and then XML). JSON5 just helps by giving it a name, a consistent implementation, and packages for many languages. I've rolled my own JSON+comments (or "static subset of Python / JS literals") multiple times, and am glad there is a community standard now.

The trailing comma is really an issue, because it works in JS, and it is an arbitrary restriction in JSON. If you learn JSON on the job (and think of it as "JavaScript Object Notation" i.e. JS literals) then you will run into this, and it causes unneccessary frustration.

Since every JSON5 package I know produces valid plain JSON, compatibility is never an issue.

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

#200

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…

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?

> Under that argument, why bother improving anything?

That's not the problem, is it?

The choice you're faced with is breaking compatibility just to add little to no value.

Post reply on HN