Why Ruby Shouldn’t Be Your Next Programming Language (Maybe)

There are two ways to view programming languages. One way is to view a language as a tool like a hammer or a screwdriver. This view states that programming langauges are tools which help developers perform tasks. Some languages, like SQL or Prolog, are like that oddly shaped tool rattling around in the bottom of your toolbox you bought 5 years ago to work on the CV joints of your cousin’s 1982 Toyota Corolla. These languages are targeted at either one or at most a very small number of problem domains. Like that funny shaped tool they are mostly useless outside of their intended uses.

Other languages, like C, Java, Perl, or Ruby resemble the well-worn screwdriver used for everything from tightening screws to stripping wire. They are not tailored to any specific problem domain. Instead they are applicable to a wide range of problems. Because of their wide applicability general purpose langauges command the majority of developer “mindshare”. That is to say most developers invest more time becoming proficient using general purpose tools compared to specialty tools.

The tool-based view is entirely pragmatic and represents the practical relationship between developer and programming language. Developers use programming languages to write programs which solve problems. Straightforward statement, right? Wrong. Programming languages have properties beyond their tool-ness. Most important among these properties is the influence programming languages wield over how developers reason about problems. A new type of hammer, screwdriver, or nail gun does not change how a carpenter reasons about his work. Having exposure to and knowledge of a broad range of programming langauges will change how a developer thinks about computing and problem solving. It can be the difference bewteen an utter kludge and an elegant hack.

Which leads to the second view of programming languages. This view states that in addition to their role as tools progrmamming languages are vocabularies developers use express problems and solutions. In this way programming languages are to problem solving as speech is to thought. It would be very difficult (at least for me) to think any non-trivial thoughts without also knowing a spoken language. Programming languages provide the vocabularies for our thoughts about computing and problem solving. As different spoken languages give rise to different schools of thought so to do different programming languages give rise to different “schools of problem solving”. Speech and programming language knowledge controls not just what we think but more importantly how we think.

Think Different

There are two major camps of programming language syntax: Algol and Lisp. All of the current mainstream languages implement an Algol-like syntax. And for the most part they have similar features. Where these languages vary is in their syntax. Javascript looks nothing like Perl. Yet if you’re familiar with Javascript your can read and get the basic gist of a Perl program. Java and C++ developers similarly have little problem reading programs written in Ruby or Python and vice versa.

Contrast this with the Lisp-like languages. Their syntax is drastically different from the Algol family of languages. Developers familiar with Algol syntax have a very difficult time reading Lisp programs. Where the Algol-based languages vary widely in syntax the Lisp family vary little. The parenthetical Lisp syntax is regular and uniform. Where Lisp and Scheme implementations do differ is in their bundled libraries which is where the Algol-based languages are mostly consistent. CPython and IronPython have similar language libraries while Gambit Scheme and PLT Scheme do not.

So, if a developer is already familiar with one Algol-based language how much benefit will they receive from learning another Algol-based language? Most likely the developer will pick up a new syntax without learning any new core concepts. In general the benefit a developer receives from learning each additional programming language incrementally decreases. The benefit never actually reaches zero because either something new is learned or previously known concepts are reinforced. The maximum possible benefit is decreased when a developer learns a language similar to one he already knows.

For example, consider a developer just starting his programming career. The first language he learns is C. The benefit he receives is 100%. Prior to learning C he lacked the vocabulary necessary to reason about computing and develop programs. In a few years he decides to pick up Java. He learns about OOP, distributed systems, and garbage collection. The benefit for learning Java is let’s say 50%. He didn’t learn as much as his first exposure to programming but he still learned a number of new concepts. He then dabbles in Linux and decides to learn Perl. His benefit for learning Perl is 25%. He still learned a few new ideas and reinforced existing concepts but not as much as when he learned Java nor nearly as much as when he first learned C. Finally he decides to investigate all this Ruby On Rails hype so he picks up Ruby. He learns a few new concepts and gains exposure to a fully dynamic programming environment. His benefit for learning Ruby is 12.5%. And so the progression goes for each new Algol-based language.

The main reason for the decrease in benefit is that learning a new Algol-based language, once you know one, is all about reframing existing concepts and ideas in a new syntax. In fact one could argue that you’re not learning anything new at all, just new ways to express concepts you already know. Of course the same is true for the Lisp-family of languages. The point is staying within one family of programming languages drastically reduces the potential benefit for learning each additional language.

Let’s take the same developer thru a slightly different progression of languages. Assume he still starts with C and Java since that’s how most developers start their careers. Now he decides to learn Scheme. Learning Scheme exposes him to a bunch of new ideas like: code as data, thinking recursively, and a functional programming style. His brain is stretched in new and interesting ways. I’d argue that he gains a 75% benefit compared to learning Java. The benefit will never reach 100% again since he can only learn how to program for the first time once. But it is higher than Java since he has learned several new ways to think about programming and problem solving.

Why You Shouldn’t Pick Ruby (Maybe)

So how does all of this relate to Ruby? I hope I’ve illustrated the decreasing developer benefit for learning additional languages in the same family. Does this mean that once your know C or Java you should never learn another Algol-based language? No. That’s not a realistic position given the economic demands of the industry. What I am suggesting is that when it comes time to learn a new language take a step back and survey the landscape. Try to really stretch your mind every once in a while and learn a programming language quite different from the ones you’re used to. There are a huge number of programming languages out there. And while learning some of them will not improve your resume or result in any paying work they will improve your mind and reasoning ability. That is what ultimately separates truly good developers from the mediocre.

Update: I’ve posted a follow-up to this article here.

Tags: programming+languages, algol, lisp, java, ruby