The title is a reference to this blog post. The author writes
Before I talk about how I evaluate languages, I want to make something very clear. There are very few cases where the language choice actually matters. There are things you can obviously not do in some languages. If you write frontend code, you don’t get a language choice. There are also specific contexts where performance is important and X language just won’t do, those situations are quite rare. In general, language choice is usually one of the least important issues for a project.
I strongly disagree with this statement in general. Of course there are many cases where it is true, but as a general statement that every developer should learn, I don't think it's anywhere close to correct.
I would say that one of the most important things you can do is choose the correct language. Here are some things that you do need to take into account when you're working on a software project:
- What are the performance requirements? This is not limited to the small subset of programming problems, like high frequency trading, where you need to squeeze every ounce of performance from the processor. Is the interface responsive? Will the program scale? Can I write in an idiomatic style, or do I have to resort to things like vectorization, which destroys readability and is hard to do? Performance concerns are not as big as they used to be, but they are not rare. Jeff Atwood had a few things to say about performance a while back.
- How am I going to model the problem? Sometimes a functional approach is best, sometimes an OOP approach is best, and sometimes you just want to write a quick script. Haskell's not the right choice for an OOP program. Java's not the right choice for a script. But it's more than that. We resist doing things that our language doesn't do well. We limit our projects to the things we can do easily in the language we've chosen to use.
- Which libraries do I need? Not all languages have equal access to libraries. Even if they exist, they might not be complete, they might not be supported, they might not be documented well, or they might be awkward to use. Poor/nonexistent library support can sink a problem or require a costly rewrite.
- What parts of the ecosystem have to be strong? If you prefer using an IDE, some languages are better choices than others. If you run into trouble, is there a community that can help you? Is there good documentation to guide you to do what you need to do?
- Which languages are fun to use? Nothing can kill your motivation like having to use a crappy language. If you dread the thought of open the project up because the language sucks, I can say with certainty that you will be less productive. If a language is fun, and you enjoy learning about it, you will leave for the office 30 minutes early and stay 30 minutes late at the end of the day.
- Which languages do you know well? Do you need to hire others to work on the project?
It's surprisingly common to see people say the choice of language is unimportant. I find that argument to be bizarre. You wouldn't expect a mechanic to say "The choice of tools is not important. If all you have is a hammer and a socket set, use that." If you ordered an Uber and the driver showed up in a Kenworth T800, it's not likely that you'd think "The choice of vehicle isn't important. All we need is a tool to take me from my house to the airport." Sure, you'd have plenty of space for luggage, but it would not seem to be an unimportant implementation detail. And you wouldn't say the choice of spouse is an unimportant detail so long as they are capable of carrying out the spousal duties.
No, the choice of language matters, and it matters a lot. I won't speculate on why someone might claim otherwise. It is an observation that conflicts with my experience.