How often do you hear the phrase "the right tool for the job" in the technology world? In many cases, it is referred to the choice of programming languages to use and how beneficial it would be to choose the right programming language to solve a specific type of problem. It is also frequently used in discussions and forums to respond to or even attack those who religiously advocate using language A versus language B.
"The right tool for the job" advocates often claim that you wouldn't use a screwdriver for hammering a nail or a wrench to dig a ditch. So why would you use the "wrong" language to solve coding problems? The analogy may be interesting, but far from real. Screwdrivers, hammers and wrenches cost somewhere between $5 and $20. Okay, decent ones may be a little more. It may take a decade to master a language like Java or Python. Sure, you can learn the syntax in a week, but true mastery of a language and its intricacies is a large scale investment of time.
Mastering a programming language is more akin to mastering a musical instrument. Playing an amazing solo on the guitar or a jazz standard on the piano takes years of practice and discipline. While it may be beneficial for your growth as a musician to learn to play multiple musical instruments, the overwhelming majority of virtuoso musicians specialize in one instrument and focus on developing their skills playing it.
It depends. In some cases, certain languages are the only languages available for a domain or have a very clear advantage over all others. Examples:
- If you are using a relational database, then you may want to master SQL.
- You have to learn Java (or Kotlin) for Android development.
- You have to learn Swift (or Objective C) for iOS development.
- C++ is almost a must for desktop/console game programming.
So, if "the right tool for the job" refers to the above cases, then by all means, you should choose the right tool for the job. On the other hand, if you are choosing a shiny new language because it is the "coolest" thing this month and can print "Hello World!" in two less lines than Java, then you may be on the wrong track.
There clearly are differences in productivity among programming languages. For example, dynamically typed languages tend to be more productive than statically typed ones, at least when it comes to initial prototyping (surely not for maintaining large code bases). There are also performance differences, where the opposite may be true for dynamic versus static typing. Developer happiness is also a factor. Some developers love Node while others take pride in writing Scala. These differences should not be the only factors to consider when making drastic moves from one programming language to another and embarking on massive rewrites of code. The loss of expertise and the associated learning curve should be critical factors in making such a decision.
This article is not advocating that you should never give up Cobol and that you should start writing deep learning code with it (who knows, there may actually be a library that allows you to do that). At the same time, as new technologies emerge, it may be best to take your time and wait to see if they grab market share and become leaders in their space. And most importantly, make sure the technology truly offers something substantial before abandoning years of investment you put into your existing knowledge and code base.