Why engineers can't be rational about programming languages

Huge problem with the conclusion, and it is something mentioned in the article. It is suggested to view the language choice as an economic decision. But guess what, that is already what the decision makers think they are doing.

There's another almost-got-it in the article. He is suggesting people tie their identity to their programming language of choice. This seems odd to me, because we tend to think of identity as think like religion or ethnic group, not sub-professional groupings like neurosurgeon or devops, and certainly not specific to tooling ("I'm a DeWalt carpenter!")

The missing connection is back to economics. If I've spent a bunch of time coding .NET, it's going to cost me something to code Java or python. This is the actual economic conversation being had. People will have to learn a new toolset, while having deadlines over their heads.

The solution is actually this: You hire people who are language-agnostic.

I used to spend a LOT of time in VBA, and then .NET. I was daunted by making the jump to C, then c++ and python. Only over time did I overcome the nerves and move on with Java, Kotlin, Elixir, js, and Rust. It was an eye-opening experience that you could do this. Just make the leap, and you find it wasn't that far.

If you don't have people who have done this a few times, you will get resistance, and the real resistance is they don't think it's worth it to put in the hours to learn the new tools. They come up with all sorts of justifications for why things are fine with the old tools.

You'll also become a language lumper if you do this. I don't really think there's a lot of language features. The main ones are GC vs manual memory, strong vs weak type, imperative vs declarative. Once I had a few points on these axes, a lot of things eased when it came to new languages.

> A new language / style / technology / whatever very often will leave us less competent.

This may be a big factor in rejecting unfamiliar languages. Over time the brain trains itself to grok a specific syntax, and understanding becomes partly automatic: we look at a Java program and our brain injects meaning into our consciousness. If we then look at APL or Lisp, however, that training on Java doesn't apply and the automatic injection doesn't function. We're left having to read the symbols directly, and it's unsettling not having the auto-assist. It makes us feel we "can't" understand the language, when it would likely take a couple weeks of immersion to change that impression.

Language choices does make a decent difference to time spent, bugs, extensibility. Id guess a 20-100% tax for choosing the wrong language. However most of the time the best language is the one the team knows well. Caveat to that is if the threading model or performance doesnt suit. Or company platform engineering reasons (e.g. availability of platform libraries).

Because his first experience with this debate was forcing PHP on engineers who knew that would be a bad choice. No matter what you are doing, PHP isn't the right choice for it if more than 1 person will ever use or depend upon the software.

PS I've seen PHP destroy billions in value in my career. It and Brainfuck are the only 2 languages you should never use to make software for other people. Every other language has a core use it is good at. JS in the browser, Python for scripting, Java when you need good observability and 3rd party libraries, etc...