Hacker News Reader

Comment by Barrin92 | Hacker News Reader

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 circles, in particular in the world of javascript and npm

View on HN

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 pedantic formats, and extremely hand-optimized systems. I just wish there was some more awareness of the trade-off they're making and making small inconvenient, but technically lighter trade-offs, these codebases can obtain very dramatic speedups.

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.

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.

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 performance is always beyond reasonable at the first iteration.

So with this logic, I’ll just prefer “vanilla json” whenever I need to use it as a data exchange format, or a well established and fast XML parser, and leave at it.

This logic made my life way easier, but it’s just me, and I respect other developers’ choices.

Mine is just an observation rather than a rant.

OTOH, using a simpler set of components will reduce the probability of breakage a lot, too.

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.

That’s my hope too. In fact the idea is very neat, but it involves humans. So I’ll just observe. :)

This might be a preference revealed in which libraries people choose but I think it is not really exhibited in the kind of libraries or code that people write. You aren’t seeing the vast majority of libraries that aren’t convenient because they don’t get released as open source or become popular.

In my experience, some of the projects which have been most valuable have been those which follow a theme of ‘do something really horrible or annoying inside our program so that the users don’t need to deal with the nastiness’. For example it might mean having to write code with some unpleasant hacks or in a very weird way to fit underlying apis or performance requirements; or it could mean spending a bunch of time manually tuning some heuristics because those heuristics improve the library.

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

is-odd

Ten years?

He is ignoring the haters. He continued despite their comments. He is mindful that the haters exist (which you have to be, in order to ignore them), but is ignoring them with respect to the advice they offer.

The haters were also wrong. They completely misunderstood the needs of the target audience for JSON5. They forgot the world is a messy place, no matter how clean and clear the JSON spec may be, the input from random users may well be messy...

I'm guessing even you simplify your life by using autocorrect and spell check from time to time. Autocorrect has its issues too, it probably makes us lazy and sloppy, but on the whole, it improves the input experience for a lot of users, so on balance, people choose to keep it around.

I don't use autocorrect, I find it does more harm than good. I do use a spellcheck to highlight "errors", but it's then up to me what action to take (and often the answer is that it was't an error at all).

Reply on news.ycombinator.com