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.
Ignore the haters, and other lessons learned from creating JSON5
31–40 of 211 posts
Re: Ignore the haters, and other lessons learned from creating JSON5
#32I 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…
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
#33Honestly 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 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
#34The 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.
Re: Ignore the haters, and other lessons learned from creating JSON5
#35I'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.
Re: Ignore the haters, and other lessons learned from creating JSON5
#36Honestly 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…
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
#37Earlier 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.
Re: Ignore the haters, and other lessons learned from creating JSON5
#38The 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.
Re: Ignore the haters, and other lessons learned from creating JSON5
#39Json 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.
Re: Ignore the haters, and other lessons learned from creating JSON5
#40Honestly 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…
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.