Prahlad Yeri

Freelance Programmer and Writer

How to approach and evaluate programming languages for a project


While it's a topic which has already invited hair splitting debates ad nauseam, it has also invited a lot of hype and there is a need to unclutter that hype and think about this topic objectively.

The Toolbox Approach

This has been the classic or traditional approach when programming used to be much simpler in the earlier days! "Right tool for the right job" used to be the motto once and you never thought of using a hammer when a chisel was needed. Around the early part of this century, languages began to consolidate and the result is that we only have a handful of highly popular ones used in the industry today and the rest are cast away into specialized domains.

The Paradigm Approach

The paradigm approach once was and still is popular today, in fact this is one way of thinking that contributes to the toolbox approach. Procedural languages like C and Rust are naturally built for system programming work or in situations where that last bit of computing performance is needed. The OOP paradigm in languages like C++ and C# helped build most of the desktop world citizens we use today such as operating systems, office suites, internet browsers, IDEs, etc. Python's dynamic nature is similarly suited for data analysis work and PHP's "all paradigms embracing" philosophy once made it a popular choice for web development. Same could be said about JavaScript to some extent, though it's a language choice that's more like thrust upon the web developers instead of being a natural choice! This is a highly subjective view, of course, all kinds of arguments can be made here depending on your own tastes and preferences.

The Ecosystem Approach

This is what I consider to be a modern approach of evaluating languages. Programming is no longer simple like it used to be once, today each major language has a comprehensive open source ecosystem built around it, and since these communities collaborate among themselves to not only build redistributable software packages but also help their users on coding forums, etc., they become a very important factor or consideration in taking the decision to use that language itself!

Consider the strange case of PHP, for instance. It's almost treated like a pariah in many programming circles, you'll find very few courses having PHP in their curriculum and not one major coding forum, blog or discussion site has a PHP topic included except Stack Overflow. But still the language is almost entirely powered by its community or ecosystem! It's also a language that pioneered open source development and collaboration by involving contributors on massive scales with projects like Wordpress, Drupal, Joomla, Laravel, etc. which have all become ecosystems in their own right.

A technology startup which is already hard-pressed in today's economically stressing times will obviously want to leverage the power of open source software and free tools, and that's where the ecosystem comes into picture! How friendly is the community on discussion forums and how large is the package ecosystem are typically the top questions in the minds of technology startup entrepreneurs.

In this regard, Python, PHP and JavaScript are the major champion ecosystems and perhaps top the list of usage surveys, they've developed elaborate package management systems to serve their bases - PyPi, Composer and npm respectively. This trend has caught to some extent in the C# and Java world too with nuget and gradle/maven but theirs seem to cater to mostly the enterprise world, there doesn't seem to be the same kind of buzz among the startups for these languages.

Summarily, these are the three major approaches for evaluating a programming language. There are others too, a major one being local availability of professionals skilled in a language. But in the age of remote working, I'm hoping that factor should become less important as time progresses. And there are "contrarian coders" too who will invest in learning long obsolete languages like COBOL and FORTRAN hoping that the skewed supply/demand ratio for these skills arising due to the need for maintaining legacy systems will ensure they get hired with handsome perks. Indeed, that's an approach or way of looking at things too!