If you’ve been following this blog, you understand that we believe in giving back to the community. You also know that our personal contributions are likely to follow our personal passions. As an author and expert on programming languages, I love to share that passion.

A few weeks ago, I had the great privilege of speaking to the Vandegrift High School Robotics team. I wasn’t there to speak about building robots, or even programming them. I was there to warn those gifted students who may be planning for a career in computer science.


You see, the programming industry is changing. Hardware manufacturers are unable to make chips faster with each iteration the way they used to. Instead of packing more on a chip by building ever more densely packed chips, we’re building multiple chips, and stacking those to greater and greater depths.

Here’s the problem. We might write code that runs on two cores, or even four, using roughly the same approach that we’d use on a single core, but the techniques that you’d use to program a single computer with a single thread are not the same techniques that we will use to program thousands of cores. The languages that we will use are likely to change too. Many in our programming industry are scrambling to understand the implications of such a dramatic change, and those who are not yet paying attention should be.

Such a dramatic change in the programming landscape should not surprise you. We’ve had explosive changes in the prevalent programming paradigms every twenty years or so.

  • Cobol and Fortran ruled in the 1950s. These were the first commercially popular high level languages.
  • Structured programming exploded after Dijkstra’s paper called “GoTo Statement Considered Harmful” was published in 1968. C became the hot implementation language in the mid 1970s and many developers learned to code using Pascal.
  • Java made object oriented programming popular in the mid 1990s, and languages like C++, Ruby, C#, and Python have followed suit.
  • The next programming paradigm is likely to be functional programming, a programming language with a strong mathematical foundation that makes writing concurrent programs simpler. These languages typically are more powerful, meaning they can express similar concepts with fewer lines of code. They are absolutely better at managing the multicore architectures we’re likely to see. Though this paradigm seems to be gaining traction, no single language has yet emerged as a clear market leader.


If you’re a programmer today, your path is clear: you should start to learn the next programming paradigm, in your free time if necessary. That way, you won’t be blindsided with what may be a violent change in the most prevalent programming languages.

If you’re a student, though, you may have a bigger problem. You see, most universities are not particularly prepared to teach the techniques that you’ll need over the next couple of decades. Accreditations, which usually work in our favor by providing a certain uniformity and excellence, can become stale. Also, it’s tough to design a curriculum around what might be. The result is that you’re not likely to find functional programming taught as the center of a programming curriculum. There are a few, though.

Still, there’s plenty you can do without looking for a core curriculum based on functional programming.

1. Learn functional techniques using object oriented languages. If you’re using languages like Java, you can use closures, or functions that you can treat like objects. My friend Venkat Supbramaniam wrote an excellent book called Functional Programming in Java explaining many of these concepts. Languages like Ruby and Python make excellent choices for learning functional techniques in an object oriented language. If you code, you don’t have to learn a new language to get on this path today.

2. Experiment with functional languages on your own time. If you are a game programmer, check out Elm. If you like Java and are comfortable with the syntax, check out Scala. If you are a Ruby or Python fan, you may find the syntax of Elixir to your liking while you explore the radically different engine under the hood. If you like to program robots, check out Clojure. All of these languages have much to teach you. Whatever you choose, get started right away.

3. When you are choosing a school, don’t pick one that will box you in. A great school that is going to bury you in Java for four years is not your friend. Similarly, a school that is just off of your A list but has excellent classes in concurrency or functional languages may move up your list.

4. Once you’ve chosen a school, find out where the hidden classes are that teach functional techniques. Classes in concurrency (at least, those that don’t teach old school threading and locking), artificial intelligence, logic, and the like may not top your lists as concepts, but they may offer you exposure to languages that will help you shape the way you think about programming.

5. Stick to it. If you move toward this path, you may find that you are initially not as productive as you otherwise might be. Don’t worry. You’re just learning a new way to express yourself. Just as spoken languages are tough to learn, computer languages are too.


Recently, we announced that we’ve been working with Eric Meadows-Jönsson. He’s a great programmer. At 24, he’s already on the core team for the Elixir programming language, and is already speaking with and to some of the best coders in the world. Without his exposure and mastery of this new family of languages, these opportunities would not have been available. We are an industry in transition, and the next few years, maybe the next full decade, will be extremely rewarding to those who are paying attention and take steps to prepare themselves.

The future will belong to the prepared.

Happy coding.