Why are you still programming in language X? Why not switch to Y?

I hear this sort of question over and over, where X might be one or more “older” languages (old is usually considered eight or more years old) and Y is a “brand new” language, that might still be young enough to have its age measured in months instead of years.

I know and use several programming languages in my software and firmware development projects. There is a core set that I use most often, because they happen to be the right tools for the job. Early on in my programming education, I learned several languages which I almost never use, because they aren’t as good a fit for the kinds of projects I happen to be working on.

I personally have nothing against the any specific programming language (except for a few issues I have with JavaScript). But please forgive me if I don’t drop everything and evaluate and learn every new programming language that appears on the horizon.

These days, my time is increasingly valuable. To learn a new language thoroughly, there needs to be a compelling reason to do so. The fact that a language is new and bright and shiny and has a lot of vocal supporters doesn’t mean that we all should drop everything and switch to it, or even necessarily take the time to evaluate it. I learn new things (including new languages) all the time — it’s just a fact of life in this business. The learning never ever stops. But I have to carefully choose what I spend time learning, because at the end of the day, I need to be productive. My employers and clients need actual results. I learn a new programming language as the need arises, or when I see a clear trend that requires my attention. In other words, I learn a new programming language when there is an actual compelling reason for it.

Programming languages are chosen for projects for a variety of reasons. Here are the reasons I’ve observed over the years, on real-world projects:

  • Availability of appropriate development tools for the target platform
  • Integration with an existing code base
  • Existing knowledge of the development team
  • Portability requirements
  • Performance requirements
  • Available skills in the new-hire talent pool
  • Tradition
  • Management directive
  • Customer directive
  • Available libraries and frameworks
  • Design paradigm support in the language

Notice that nowhere on this list is “Because the language is new/bright/shiny.”  The programming language’s age should not be a serious criterion for language selection, for a non-trivial project in the real world. Proof of concept, sure. Academic exercise, yes. Real-world project, no.

There are always new languages popping up here and there. Some will forever remain niche, some will catch on, and some may alter the landscape of the software development world forever. Have a look at this programming language influences network, and when you get to that page, zoom in to see more and more languages. Then consider the time it would have taken to thoroughly learn each of these languages soon after they appeared, and extrapolate that into the future — because new languages will continue to be added. Even if you learned them all thoroughly, you would end up using only a small subset of them for real-world, non-trivial projects.

There is nothing wrong with learning and using a new programming language. Just do it for the right reasons.

Leave a Reply