Most of us write software in environments with ridiculous deadlines. We don’t have time to investigate every new thing. My purpose in this article is convince you that Function Programming + Immutable Data + Massive Parallelism (which I will henceforth abbreviate as FIMP, is not just another new thing, but is an important collection of new technologies and a reasonable and obvious response to the fundamentally-changed/changing computing environment.
Elixir makes FIMP feel natural.
Remembering Programming Paradigms
I’ve been programming long enough to have lived and worked through four programming revolutions:
- The adoption of High Level Languages (Fortran, Cobol, etc.) for real work. Bye-bye assembler language.
- Structured Programming, using top down design, stepwise refinement, etc.: PL/1, Pascal, and C, among others.
- Object Oriented Programming: Smalltalk, C++ (?!), Java, etc. Today’s dominant model for software construction.
- Functional Programming + Immutable Data + Massive Parallelism: There are many new languges addressing all or parts of these changes: Haskel, OCaml, Clojure, and especially, Erlang and Elixir.
Professional programmers should be familiar with the first three, above. As for the last, most have probably heard of Functional Programming, but may not be familiar with its relationship to Immutable Data (which is not what you think!), or Massive Parallelism. (How masssive is massive, anyway?)
I’ve been playing with Clojure, Erlang, and other functional languages for several years. Even for a lover of Scheme, it was disorienting at first, but so was OOP when I first encountered it.
Recently I’ve discovered Elixir, which I especially recommend because of the familiar, Ruby-like syntax; its excellent environment for dependency and package management, building, setting up new projects, etc.; and how it makes FIMP accessible to programmers that have better things to do than learn obscure, interesting, but impractical technology.
If you’re like me, OOP has become second nature; it’s easy to slip into the erroneous belief that Objects are really what software is all about. But I invite you to Google “problem with object oriented programming” and read a few articles. My guess is you may find yourself nodding your head more than you might expect.
A Changed Computing Environment
Recently we’ve seen,
- Much larger systems and increased complexity of requirements coupled with a desire to construct systems from smaller, reusable components.
- Multicore processors inside the local computer system.
- Constructing big distributed systems out of smaller systems that communicate with each other over LANs or internets.
A Few Key Features of Elixir:
- Purely functional (buzzword compliant!) with first class functions; tail-call optimization; recursion instead of looping; pattern matching for function invocation, destructuring, etc.; and great libraries of functional building blocks.
- True concurrency and parallelism without semaphores and locks; ability to use massively multiple processes or threads, where “massive” means hundreds of thousands of threads at low cost and the ease approaching that of function calls.
- Leveraging threads/resources across cores and across the network with equal ease; real bullet-proof distributed system failure recovery of just the failing parts of an application.
- Hot (“on-the-fly”) updating application code while it’s running.
- The core language is small, clean, consistent, functional, extensible. The power of Lisp macros for extending the core language, but with a pretty, readable syntax reminiscent of Ruby.
- Scaling is built into the core of the language, not added (unsatisfactorily) after the fact.
- Elixir runs on the Erlang Virtual Machine, a mature architecture for distributed systems that has been in use in the telecom industry for decades.
Settled into comfort with my dogma that objects are the way to think about software construction, it was mind bending to realize that, with a few minor exceptions, many things that are hard or impossible with Object Oriented Languages, are easy in Elixir. The catch, to the extent that there is one, is that Elixir (or Erlang, or Clojure) requires a change in ones habits of thinking about software construction.
Our current tools are reaching the limits their ability to deal with new hardware realities. Elixir (et al) show the way forward.
I don’t want to minimize the challenge of adopting new software techniques and tools, but do yourself and your career a long term favor and look into this different way of thinking about computation and software construction.
For Further Study
This would be a very long article if I got into all the details, and others have done a better job than I could do. Here are some references to continue your investigation:
- A 30 minute video by Dave Thomas. Excellent.
- http://pragprog.com/book/elixir/programming-elixir Dave’s book from which much of the above video is taken. The e-book is available now; paper this Fall.
- http://elixir-lang.org/ The Elixir language web site; pointers to a lot of other resources.
- http://joearms.github.io/2013/05/31/a-week-with-elixir.html Article by Joe Armstrong, inventor of Erlang. Find more by Googling “Elixir lang”.
Don’t become that guy who still thinks Cobol is all he needs, a decade after the world has moved on. Java, Ruby, NodeJS, and (fill in your favorite language system) may be today’s Cobol.