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.