Live data from Hacker News

Ignore the haters, and other lessons learned from creating JSON5

aseemk.substack.com

31–40 of 211 posts

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

#31

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.

I think you will find that a great diversity of minds are attracted to this site, and for reasons you may not have considered. Curiosity is a giddy thing, and it is a fundamental part of what draws me here. If you read this site and see only the occasional jerk rather than the experience-driven insights, that is your misfortune. Maybe instagram is your thing. I hear they have a lot of cat pictures.

No post body was provided.

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

#32

I don't think writing an article about hackernews comments from two years ago is exactly what I'd call a lesson in ignoring the haters, but this reads a little bit like someone writing an article about the roaring success of null references after their adoption. despite popularity, most of the technical comments in that original thread aren't wrong. 'Popular', 'Easy to adopt' and 'a very bad idea' can be overlapping…

From my experience, the current generation of programmers value convenience beyond everything else, with a great margin. This is not wrong per se, but it calls for much more complex code which handles all the edge cases, and hurts performance at the end of the day. Then, this small performance penalties pile-up and the same developers ask why their code is not working as fast as it should. I don't call for very pedan…

I don’t think this is in any way specific to the current generation of programmers.

The generation that learned with BASIC or used Smalltalk or Lisp in college is decidedly an older generation at this point.

If performance is important, you profile. Optimizing your configuration format for parsing speed is likely a bad decision unless you’ve identified that it’s a problem.

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

#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 think only of the simplest version of it)

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

#34

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.

Given you're leaving a criticism on HN, I infer from your own comment you're not worth listening to.

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

#35
post #30
post #8

I'm kind of appalled that the Hashicorp guy went that far to put someone down for just building something they found useful to themselves. What a great way to discourage someone from expressing themselves creatively. Glad Aseem carried on regardless.

I wouldn't want to work for some company whose founder can be openly toxic against a project that solves an actual problem.

Perhaps he's jealous as half of Hashicorp's portfolio only create more problems than you had originally...

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

#36

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.

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

#37

Earlier quoted context omitted.

From my experience, the current generation of programmers value convenience beyond everything else, with a great margin. This is not wrong per se, but it calls for much more complex code which handles all the edge cases, and hurts performance at the end of the day. Then, this small performance penalties pile-up and the same developers ask why their code is not working as fast as it should. I don't call for very pedan…

I don’t think this is in any way specific to the current generation of programmers. The generation that learned with BASIC or used Smalltalk or Lisp in college is decidedly an older generation at this point. If performance is important, you profile. Optimizing your configuration format for parsing speed is likely a bad decision unless you’ve identified that it’s a problem.

Performance is a relatively minor problem here, complexity being the bigger concern. For example, I really love all-in-one programs like Rust's 'cargo' and Nix's 'nix', but the work that goes into making them work properly is astronomical. On top of that, both of those programs have limited composability and fight for dominance with other interlocking tools like rustc and nix-env, respectively.

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

#38

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.

There's a lot of critics, then you look at their accomplishments and it's unsurprisingly sparse.

Some people get paid in money and not exposure.

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

#39

Json comments is something I always wanted, for json files with data that you need. I even use regexp to remove them in some cases (where I know it won't conflict with the strings themselves). Didn't knew about this json5 thing but I'll try to use it instead.

If you just want comments (and trailing commas), there is also this: https://www.npmjs.com/package/jsonc-parser

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

#40

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 disagreement here is where in the design space between JSON and YAML is the right syntax for configuration files.

Post reply on HN