If you're reading this, I assume you're ready or at least thinking of taking the leap into a new challenge: that of learning (more) functional programming, and considering learning a functional language. This is a great idea! But with so many functional languages out there, which one should you choose?
The following remarks expand on the epilogue in my book Functional Programming in C#, so by time the reader reaches the epilogue, I assume he’s already learned to think functionally, and to leverage functional techniques in C#. Indeed, there’s an important difference between:
Thinking functionally is the really tricky bit. The order in which you should approach these two depends on your background.
If you're fairly new to programming in general, you're lucky: just skip down to the list of languages.
Doing all this while at the same time learning the syntax, libraries and tools for a new language can be overwhelming. For this reason, I suggest that your first approach to functional programming should be to learn to code more functionally in the language you're familiar with. (If this language is C#, then my book was written for you.)
I say this because most mainstream languages are multi-paradigm, so they offer some support for functional programming. At a certain level, you can program functionally in any language that has:
(For more on this point, see my previous article Is C#7 starting to look like a functional language?)
So, let me assume you've come to the point where you use functional techniques regularly in your daily work, especially higher-order functions, immutable data structures, and so on.
Should you still learn a functional language? Of course! You will need to, if you want to go deeper. In a multi-paradigm language, you can mix and match between the different approaches the language supports. A functional language, on the other hand, will force you to use the functional approach throughout — for example, by not allowing any state mutation at all. And naturally functional languages have better syntactic support for functional techniques than multi-paradigm languages.
An additional benefit of learning a functional language is that it will allow you to take advantage of other learning resources: books, blogs, talks, and so on. Most learning material on FP available today has code samples in Haskell or Scala.
Which language you choose will depend on what you want to get out of it, so I'll discuss this next.
The natural choice would be to learn Haskell, which is the functional language of reference and a lingua franca among functional programmers. Most of the literature on functional programming — not just academic papers, but blogs and other online resources — has code samples in Haskell.
For this, I recommend you read Learn You a Haskell for Great Good by Miran Lipovača. You can read the full contents online for free, but do consider buying a copy to reward the author’s hard work.
Another good way to learn Haskell is to do so while following Erik Meijer’s MOOC on functional programming on edX, which you can follow along in Haskell or one of several other languages.
Haskell is the language that every functional programmer worth his salt knows, at least to some extent, but the flip side to this is that very few people make a living writing Haskell. Adoption in industry is extremely limited (but growing), so be aware of this: if you learn Haskell, it's because there's value in learning it — not so much in using it.
Scala is a multi-paradigm language with an emphasis on functional programming that runs on the Java virtual machine. As of today, Scala is your best chance at programming functionally and getting paid for it, and the Scala community is the most active in addressing the question of how the ideas of functional programming (which often originate in academia) can best be put to work in industry.
Because Scala is compatible with Java, the fact that you're writing code in Scala doesn't mean that it's functional. This is the reason why I recommend that if you're just learning functional programming you do so using a purely functional language — not a multi-paradigm language like Scala or F#.
In other words, I recommend you approach Scala only after having learned a purely functional language, or having otherwise acquired a very good foundation that allows you to tell functional from imperative techniques (for example, having read my book or similar material).
If you want to learn Scala, I recommend you do so by following Martin Odersky’s MOOCs on Coursera. These courses stick to the functional subset of Scala.
Two younger functional languages I’m fond of are Elm and Elixir, both of which are supported by an enthusiastic user community and are gaining popularity, especially among startups. I hope to see these two languages gain wider adoption and recognition in the next few years.
As a first functional language to learn, Elm ticks many boxes, because:
Elixir is a dynamically typed language that runs on the Erlang virtual machine (this is based on the actor model, which I discuss these in chapter 15 of my book), and as such it’s particularly well suited if your interest is in systems with a high degree of concurrency and you want to explore message-passing concurrency.
There are many more functional and multi-paradigm languages out there. Just to mention a few popular ones: OCaml, Clojure, F#— sorry if I forgot to include your favourite! Each of these languages has its niche and its reasons to appeal, but I feel the languages listed above have something that truly sets them apart and makes them worth learning first.
The most important thing to remember is that functional programming is a way of thinking which is language-independent. Once you know the techniques, picking up a new functional language is easy: as part of the research for my book I learned 6 of them, and I can tell you it can be done in a couple of days once you know how to think functionally.For more information (and a discount code!) on Functional Programming in C# download the free first chapter or see this slideshare presentation.