Hacker News Reader

Comment by kubb | Hacker News Reader

But they hired someone capable of learning.

99% of developers will not learn a language that doesn’t look familiar to them on principle. They don’t like it and it’s the end of discussion.

View on HN

What a shame.

When I started out in the 1990s professional programmers generally made a point of learning new languages, to acquire skills and expose themselves to alternate ways of thinking.

I remember a boss in the early 2ks who was teaching himself OCaml in his spare time just because.

In the mid-to-late naughts there arose the diploma mills, offering short programmes to turn students into silicon valley hopefuls. It fundamentally shifted the culture of software development.

There was also a dire need for more programmers. I think the industry would take what it could get.

I love learning interesting niche languages and also wish it was still the case that learning interesting languages purely out of interest was common.

But I'm afraid that the network effects that favor large languages are only getting stronger over time. It's very hard to convince someone to learn a new language if they're used to finding the answer to almost every question they can think of on Stack Overflow and find free libraries for almost any task on GitHub. Your niche language will have neither of those things. Large languages will continue to consolidate and become impossible to displace, even if a new language pops up that is strictly better in terms of design.

Entrenched programming languages have reached the point where, I believe, they will never be displaced. So there are certain obvious mistakes, such as every object in Java being nullable, that we will have to live with in perpetuity.

There are a lot of developers that won't even learn new things about their current language. I'm still fighting to get some people to adopt C++11 which is 13 years old now.

I used to think this sort of "unreasonable" mindset was a characteristic of "old fogies" and "bright young'uns" always knew better. But ever since i moved from the latter to the former group years ago i began to understand this mindset. It is basically a fear of losing the expertise one has acquired over a long career through a language which has become almost second nature. Also with time and experience you become very cautious about trying out new things in production code because you still don't understand the ramifications fully. For all its complexity, pre C++11 was far simpler to understand and write code in. We knew the minefields and what to avoid and how to model effectively. So most of us are not a fan of new additions to the language every 3 years just because the committee members are trying to ape other languages. Speaking for myself, i only wanted a concurrency library and some compile-time programming constructs as new additions to the language, everything else was strictly not necessary.

Looked at from the above viewpoint, you should be able to appreciate us "old fogies" mindset and why we refuse to eagerly jump on the C++11 (and later) bandwagon just because it exists. We need a justification for every new thing we are forced to re-learn and use. So my suggestion is to take one new feature at a time, discuss and convince the folks of its utility, maybe make the changes in one single module and demonstrate it. The argument of "its new and shiny" will never fly with us.

I am one of those old fogies. While some of the new things in C++ are not useful to me, there are a lot of things aped from other languages that make my life better. Those who are not interested in learning everything can sit back for a bit while those who eagerly jump to new things figure out what is good and what they can ignore (remember that each problem domain is different so we won't all have the same answer). For me, just using unique_ptr would be a major improvement.

Even the old fogies need to be aware of what is happening. I haven't yet done much Rust, but the advocates (when I cut through their Rust religion) are saying some things that really speak to my pain points and so I'm planning to learn it (and have been for a couple years - I may retire before I get around to it, but some new and shiny things are not just glitter and so it remains on my list)

Ah; a kindred "old fogey" :-) Yes our experience shapes how eager we are to jump to learn new things. But it is eventually done at our own pace. In general though, with age and experience people become more cautious psychologically. Probably because we have made so many mistakes which in hindsight could have been avoided if we had thought more and studied more. This is what is frustrating with "shiny new" features. Even before people have gotten some substantial real-world experience with C++11, you have C++14/17/20/23 piling on top and making us feel peak "imposter syndrome". To make matters worse, the noobs/wannabes start "cargo cult programming" with no real understanding and thus ruining the s/n ratio. They don't understand that merely learning the new syntactical features will not magically make one a better and more productive programmer.

The C++ standards committee really needs to disband itself for a decade and leave us programmers in peace :-) Stroustrup wasn't kidding when in the preface to the 4th edition of TC++PL he said "C++11 feels like a new language".

Finally, i agree that we need to be aware and keep abreast of new languages/features which are genuinely good/useful but i would rather be "slow and sure" than "fast and fail".

> C++ standards committee

Is working on things that would be useful. The early adopters of modules have reported some very intriguing results - it isn't ready for me to try yet, but so far what the standard committee has done looks like it will be a win for me in 5 more years when I finally can adopt it. Reflection and contracts are two other things coming that have some intriguing uses in the real world and I'm hopeful to see how/if they work out.

Agree with you on Reflections and Contracts (have actual fundamental value) but not so much on Modules (more incremental and restructuring).

If - as some have reported - modules can bring my compile time down significantly that is bigger than anything else and it will be worth the effort to adopt. That is a big if - modules are still in the early adopter stage and so we are still learning how they work. In general my project is late adopters.

> In general my project is late adopters.

Amen ;-)

John Lakos' old Large Scale C++ Software Design (there is a newer edition which i have not read) taught me C++ "physical design".

I think the dichotomy of script kiddies versus hackers applies aptly to modern developers. Some developers learn their frameworks and libraries and enough of the language to be productive (script kiddies), whereas some have a keen interest in understanding how a system works and the art of software engineering (hackers). Hackers in my experience are still a very rare breed.

This has been my experience with most engineers.

I can’t think of a time I’ve seen this, and I’ve worked with most languages at least once (including Haskell, Rust, Go, F#, PHP, Java, etc…)

One of the other competitors was the project head. All of those people seem deeply inclined into learning and experimenting.

Even if this is sometimes true, when you adopt this viewpoint your work turns to crap. Hire good people, and if you can't hire good people, do something more interesting.

How did they learn the languages they currently know?

Perhaps only God knows.

They took a programming camp they paid for, where they were given the task to learn the language of the day. So they learned it because they were forced to, not out of curiosity or desire to improve.

Monkeys using a typewriter were also proven to be 83% more productive than the average developer. Study suggests that their edge likely came from not understanding and ignoring the certified scrum master™.

Reply on news.ycombinator.com