Live data from Hacker News

Ignore the haters, and other lessons learned from creating JSON5

aseemk.substack.com

51–60 of 211 posts

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

#51

Earlier quoted context omitted.

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.

My sense is that it takes a lot of savvy to make good decisions about the complexity of your design and the choices about which dependencies you rely on. This takes years of practical experience to learn, and the incoming generation of programmers will always be bad at it.

Young programmers have a tendency to err in both directions, here.

Some will err by building on lots of complex systems tied together. They’ll fire off “create-react-app” on day 1, and then on day 1000 they realize that there’s just too much going on that they don’t understand and can’t debug.

Some will err on the side of rejecting “heavy” dependencies. They overestimate their knowledge of the problem domain, underestimate the flaws in code they are planning to write. They’ll create a blank repo on day 1 and on day 1000 still be working on support code that they didn’t have to write.

If you have years of experience, it’s easier to navigate the middle path. The incoming generation will figure it out given time.

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

#52
post #47

I still don't get what the point of json is. If you want to dump raw JS data structures as text just do. You don't need a spec or special tools. If you want human readable XML just use s-expressions. Something that's so easy to parse you can roll your own in an afternoon. Json is trying to square the circle of "I want things to be easy" but also "I want to not shoot myself in the foot", goals which are mutually exclu…

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

But make the brackets curly and it's fine.

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

#53

Earlier quoted context omitted.

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.

What makes you think the jerks are only occasional?

I've been reading this site fairly regularly since 2010. Not as long as many, but long enough to feel confident saying that though the cast is always changing, this site remains one of my favorite places to 1. discover things I hadn't considered previously 2. reevaluate my past decisions in a way that makes me thoughtful about future ones

It is partly the articles, but more the comments (and careful modding).

HN stands out as a great place to expand my awareness. There are people here with deep technical experience that care about the outcome of their conversations. The flame-bait and regressive behavior isn't the main thing going on, it is a sideshow. If that ever changes for me, I'm out of here.

The article fodder is not as interesting to me as it used to be, but there are gems, and the comments remain engaging.

Who knows, perhaps I'm one of the jerks? Perhaps I'm the dreamer that dreams the dream and am therefore the jerk expert? Hard for me to say, but I welcome your opinion.

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

#54

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…

> 'Popular', 'Easy to adopt' and 'a very bad idea'

is-odd

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

#55
the general attitude of the critics is correct. the name you chose has implications that are not true - JSON5 has nothing to do with JSON and you have nothing to do with the people who came up with JSON. have you named it something else, you'd receive far less (if any) negative comments.

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

#56

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…

[deleted]

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

#57

the general attitude of the critics is correct. the name you chose has implications that are not true - JSON5 has nothing to do with JSON and you have nothing to do with the people who came up with JSON. have you named it something else, you'd receive far less (if any) negative comments.

[deleted]

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

#58

Earlier quoted context omitted.

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.

My sense is that it takes a lot of savvy to make good decisions about the complexity of your design and the choices about which dependencies you rely on. This takes years of practical experience to learn, and the incoming generation of programmers will always be bad at it. Young programmers have a tendency to err in both directions, here. Some will err by building on lots of complex systems tied together. They’ll fir…

However, both sides need a good mentor that shows The Way to them, or just they tend to get stuck where they have started for a longer time than they should, IME.

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

#59

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…

What you want is something like Relaxed JSON (http://www.relaxedjson.org/), but it's not valid JS, while JSON5 is.

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

#60

Earlier quoted context omitted.

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.

Of course premature optimization is root of all evil, but JSON is a data exchange format above all else, and using a more relaxed version of it will inevitably incur a higher overhead, and its original format is just native to the language itself. I personally prefer to choose a simpler, and a bit more pedantic versions of stuff whenever I develop something, and while it doesn’t break performance records OOTB, the pe…

My assumption here is that, like you, other people will continue to use strict JSON for APIs and interchange, and use JSON5 for configuration as appropriate.
Post reply on HN