Picking the right programming language for a project can be an important business decision, and making the wrong choice is usually expensive. After reading this, you should have enough background to have an informed conversation with your development team.
Programming languages allow humans to tell computers how and what to do. Everything your computer does (browsing the web, responding to email, playing games) was programmed into the computer using a programming language. Unlike human languages with their many ambiguities, programming languages are excruciatingly precise.
There are many programming languages, and most of them have funny names: Python, PHP, Ruby, Java, Javascript, Julia, C, C++, C#, Lisp, Haskell, .NET, Lua, Perl, Go, etc.
Why are there so many, and when does it make sense to use one instead of another? This article provides a non-technical answer to both of these questions.
It’s Emotional 🔗
Before answering our two questions, we need to discuss something important that most non-programmers won’t get:
Programmers typically have strong emotional biases for or against certain languages.
This can make it difficult to fully trust the advice of a freelancer or a small software development team.
It is not uncommon for new developers to learn a single language and continue programming in it for many years without ever learning a second. This developer may argue vehemently to use the language they know, even if it is not the best fit for your project. The same can be true for small teams. If a technical team isn’t willing to consider other languages, it is usually a warning sign. There are often multiple languages that can be a good fit for a particular problem.
Different biases exist at the other end of the spectrum. Talented developers are often drawn towards and even zealously promote new exciting languages; they will argue that a new language is superior to older languages for specific technical reasons. Even if their technical assessment is correct, new languages are often a poor choice from a business perspective for the following reasons:
- they evolve more frequently, requiring your code to be updated along with the language
- there are fewer fluent developers in the language to hire
- there is less reusable code written in the language
- it is more likely that the language will die out; if this happens, you will either have to maintain the language yourself (very expensive) or re-write your project
- they have less documentation and fewer tutorials online.
You should always be aware of the popularity of the languages you are considering (check out this useful site).
Finally, there is a cultural vibe to most programming languages, and some programmers simply don’t like a particular culture. For example, developers who like the languages Ruby and Python typically view the opposing language as inferior, to a somewhat irrational degree.
What Makes Programming Languages Different 🔗
So, back to the first question: why are there so many programming languages?
In the same way that no person can be an expert at everything, no language can be well-suited for every task.
This is why there are so many languages in popular use. For example, there are languages that specialize in
- scripting 2D video games
- grabbing data from a relational database
- simulating biological systems
- identifying patterns in a bunch of text
- solving linear algebra equations.
However, most mainstream programming languages specialize in a more general sense:
- running quickly
- being easy for beginners to pick up
- running on many operating systems
- taking advantage of super computers or massive parallelism
- running web applications
- being “embedded into” other programs
- protecting against programming errors
- helping programmers work quickly.
To help exemplify how two programming languages can be better or worse at a particular task, the following is an example of the same simple program written in two different languages. You don’t need to understand the details of either to see how one is superior.
{ a; b && c; } >> log.txt
This simple program runs three other programs, a, b, and c, and stores their output in a log file. It is written in the Bash programming language, which is very terse. Here is the same program written in Python:
from subprocess import check_call, CalledProcessError
f = open("log.txt", "a+")
try:
check_call(["a"], stdout=f)
except CalledProcessError as e:
pass
try:
check_call(["b"], stdout=f)
check_call(["c"], stdout=f)
except CalledProcessError as e:
exit(e.returncode)
exit(0)
The program written in Bash is much shorter and is, in nearly all respects, better for this application. This is because Bash was designed to be good at running other programs (and not much else). On the other hand, the Python program is verbose, but Python is a more general-purpose language. For a large project, you would likely chose Python over Bash because writing most types of code in Bash would difficult, slow, and hard to understand. All of the “shortcuts” that made Bash well suited for managing processes are simply confusing in another context.
This is an example of a trade off between specificity of purpose, and general utility. Trade offs like this make it impossible for any language to be ideally suited for all tasks.
High and Low 🔗
Another important trade off involves how quickly the program runs, and is very relevant from a business perspective.
Programming languages that let you tell the computer how and what to do in a very detailed way are called “low-level”. Programs written in low-level languages can be very fast, at the cost of being more difficult, time consuming, and thus expensive to actually write. Programming languages that hide the low-level details of the computer are called “high-level”. High-level languages let the programmer worry about the big picture instead of details about how the computer runs.
There is a trade off between being “fast to develop” and “fast to run”.
Let’s illustrate this trade off with two examples.
Imagine you want to simulate traffic patterns in Austin, Texas so you can decide if they need to build another highway. In a high-level language, it would take a developer two months to write the simulation, and each simulation would run for a full week. In a low level language, it would take six months to write, but each run would take an hour. If you only need the simulation a few times, it would be cheaper and quicker to use a high-level language. If you will need to run simulations for a few years, it may be worth using a low-level language. There are other benefits to writing fast programs: if you can run the simulation in a hour, you can probably compare more scenarios and place the highway in a better location.
Now imagine you want to write a dating app for opera singers. You hire some developers to write a program that stores everyone’s hair color preferences in a database and gives the app access to this data. It may take a developer a month to write this program in a high-level language, but it costs $100/month of processing time for every 5,000 opera singers. In a low level language, it may take a developer four months to write it, but it only costs $5/month per 5,000 opera singers. Well, there aren’t that many opera singers, so the high-level language is clearly the way to go. But imagine you have many thousands of users. Processing time starts translating into a lot of money.
Finally, there are other benefits to writing fast programs. For example, Google takes into account page load speed when ranking your site in its search engine.
For most startups and business applications, you should first write the program in a high-level language. If its necessary, re-write the program in a low-level language to speed it up. Not only do you hedge the risk that you will spend a lot of time and money on an app nobody likes, but also your developers will learn from the first version, and will be able to improve the design on the second pass.
Other Factors 🔗
There are many tangential factors that should influence your choice of a programming language.
If you are expecting your software to run for more than 5-10 years, you may want to verify that there are big companies that have written large programs in the language you are considering. This reduces the risk that the language will die out and become obsolete while you are still using and maintaining your program.
If your team already knows a language and you have properly considered other choices, you should use the language they know. This is especially true for languages that are similar to each other (e.g. Python vs Ruby vs PHP or Java vs C#).
If your project involves a lot of specialized tasks, you may want to see which programming languages have good libraries for those tasks. For example, imagine you are writing a program to sift through corporate email archives for fraud; you may want to see which languages have libraries for reading email archives and performing language analysis. If one language has both, it may be worth using just for the libraries!
If your program must run on a particular platform (e.g. an iOS app), obviously you need a language that will run on that platform.
Sometimes your project may warrant (or even require) the use of two or more languages for various components of the project. Web applications require JavaScript (or a language that gets transformed into JavaScript) as well as a server-side language. And it is common to have auxiliary scripts written in other languages. That said, for your core program, coupling different languages together is painful, messy, and usually not worthwhile.
