Learn more programming languages, even if you won't use them
This article has been translated into Spanish: Por qué debes aprender más lenguajes de programación (incluso si no los vas a utilizar)
Imagine we’ve been handed a task and we’re free to choose the programming language. The assignment involves all sorts of string manipulation: reading strings, splitting strings, trimming, joining and running regular expressions over strings, everything in UTF-8 and, of course, emojis need to work. Which language do we choose? C? Oh, please no.
Another job, this time at a financial institution. We need to do tens of thousands of concurrent calculations. High performance is a hard requirement. Should we use… Ruby? Come on. Next up: a one-off script that renames a bunch of files… written in Java? A web browser… in Python? Programming a controller for a medical device with… C#? Swift? Lua? You get the point.
Different programming languages are good at different things and bad at others. Each one makes certain things easier and in turn others harder. Depending on what we want to do we can save ourselves a lot of work by choosing the language that makes solving the type of problem we’re facing the easiest.
That’s one of the tangible, no-nonsense benefits of learning more languages. You put another tool in your toolbox and when the time comes you’re able to choose the best one. But I would go one step further.
I think it’s valuable to learn new programming languages even if — here it comes — you never take them out of the box.
Languages shape the way we think*, each in their own peculiar way. That’s true for programming languages as well. Each language contains a different mental model, a different perspective for thinking about computation and how to write programs.
Take SQL, for example, and how it shapes your thoughts about the flow and the form of data in your program. Now consider what that would look like in an imperative, object-oriented language like Java, or a functional language like Haskell. Or in C. Imagine what a multi-player game server looks like in Python, in Haskell, in Erlang; streaming and processing terabytes of data in C, in Go, in Clojure; a user interface in Tcl, in Lua, in JavaScript.
Every programming language is a lens through which we can look at the problem we’re trying to solve. Through some of them the problem appears convoluted, exhausting. Through others it doesn’t even look like a problem at all, it looks barely different from any other mundane thing one does in this language.
By learning a new language, even if it stays in your toolbox for all eternity, you gain a new perspective and a different way of thinking about problems. Once you’ve implemented a game server in Erlang, you’re going to see game servers in a different light. After you’ve processed data in a Lisp by thinking of the data as a series of lists that you can mold by sending it through a series of tiny functions that can be composed to form pipelines of functions, you’ll see shadows of this pattern appear everywhere. As soon as you’ve had your first real taste of memory management in C, you’ll start to appreciate what Python, Ruby and Go are doing for you — while seeing the cost of their labour. And if you ever built a UI in JavaScript with React.js, you know that you’re thinking about UI components shifted, in a fundamental way.
These new perspectives, these ideas and patterns — they linger, they stay with you, even if you end up in another language. And that is powerful enough to keep on learning new languages, because one of the best things that can happen to you when you’re trying to solve a problem is a change of perspective.
* This is known as linguistic relativity or the Sapir–Whorf hypothesis. In the context of this article I support the thesis in certain ways, but you should know that in the scientific community it’s validity is still very much open for debate. See this article for an introduction to the problems with the thesis.