Why engineers can't be rational about programming languages

I think the assertion might even have been true for non-pathological cases 20 to 40 years ago. A company that chose Visual Basic or Perl would have had a much harder road than one which chose C# or Python. But i think the languages which have survived to the present day are all pretty close in productivity. Except C.

"I cannot agree that programming language choice is a primary driver in a product's success or failure"

I've seen it. There are definitely incorrect language choices for certain projects.

It would be fair to say that these cases are themselves often exceptions. Many projects can be equally well accomplished by teams skilled in any language. But there is definitely a set of problems for which you can make incorrect language decisions.

I'm going to exaggerate to make the point in an attempt to avoid too much argument about whether or the language would be suitable, but: You do not sit down to write an industry-leading, high-performance database whose top-level implementation language is Python. If your project spec involves running code provided at runtime by users, Go is a fairly poor choice. You can make things a lot harder for yourself trying to be too insistent about what language you'll do your mobile development in, rather than just accepting that there's a very dominant choice in those spaces.

I've also seen projects I couldn't prove to you beyond a shadow of a doubt failed due to language selection, but I am fairly certain the project I saw that chose Scala failed primarily for the choice of Scala where it was a bad fit, both technically and for the skillsets of the engineers involved.

I've also seen projects nearly fail because they chose databases incorrectly, which I would submit is a fairly similar thing. Mostly because of choosing a NoSQL database "because fast" when they should have used a relational DB. The projects in question didn't fail because they were able to switch in time, but it was a close thing.

Part of "the composition of the employees of a project" being responsible for its success is that good engineers pick at least a decent solution to a problem from day one. The aforementioned DB problem, for instance, should have been obvious from the very beginning that it was not the correct choice in their case. There are absolutely wrong choices, that can crash projects both quickly and slowly.

While I’ve seen bad technology chosen for projects, it seemed at root more a problem with the people choosing it than the technology itself.

> More often than not, preference should be given to the language most of the team know the best.

I'm sorry but I disagree. Languages are tools, pick the best tool for the job. The idea that languages are all good at everything is not true. And when I see takes like this, I tend to think that that person just doesn't understand how to assess a language's strengths and weaknesses.

Want to write ML, probably best to use a language with functions as first class types (ie a FP language). You might say, most people doing ML use Python. This came to be because the language was picked based upon what people knew. But the big companies doing ML (successfully) don't use Python anymore and haven't for over a decade. ML researchers kept FP alive for several decades when nobody else cared because FP is the best tool for ML (or for writing a compiler). Where the FP folks get into trouble is trying to push FP where it doesn't make sense. I see this pattern repeating over and over again. Languages are pitched as silver bullets when they are just screwdrivers and hammers.

Right tool for the job, ignoring this leads to "religious wars" because that's how we describe disputes which are matters of taste.

Also, you are massively overvaluing expertise in a given language. A more talented engineer who doesn't know your favorite language after a couple of months will be better than you in your favorite language too despite your greater experience with that language.

great team can write amazon clone in fortran. bad team cannot write todo list clone in… well anything :)

it is (almost) always people and (almost) never language/framework/…