[dietrichepp]

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.

[smoldesu]

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.

[dietrichepp]

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.

[bayindirh]

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.

[bayindirh]

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.

[dietrichepp]

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.

[bayindirh]

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