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.
Top comments (2)
Hi Lance, as a lot of things in software development, it depends.
Language choice is not a binary choice. It's a mixture of preference, the market (offers and availability), good old trends, requirements and more.
What a lot of big tech companies teach us, in hindsight, is that it doesn't always matter that much. Time to market matters much more and it really depends on what you're trying to do.
If you read High Scalability for a while you'll notice that the language itself is almost never the biggest scalability pain point.
That doesn't mean that it's not important. Having 3 nodes instead of 1 because language X is slower than language Y might be very important if the budget is tight. But the tight budget has to be paired with developer experience and time to market. Let's say that you use language Y which allows you to save 2 servers worth of money. What if your developers are going to take 3 months instead of 1 to finish the product because they are inexperienced, is that really the best choice?
There are domains and situations where language really does matter and usually it's about constraints (be them of speed, of resource usage and so on).
I believe that the truth lies somewhere in the middle.
There's also another aspect: a lot of people really love their language of choice, which mean that they'll actively seek companies who use it as the primary tool of development. Sometimes they'll even build whole careers around that language and its community, which means they won't be particularly interested in working in places that don't use such language.
The best choice is to learn more than one, you can't have a choice if you don't at least know what's out there.
Language choice is a hard optimization problem to solve, but it's a lot harder if you're not familiar with the options. Or at least it's harder to get right if you're not familiar with the options, but on the other hand it's easy when you don't have to make a decision.