Philip Wadler wrote an article a decade ago entitled Why no one uses functional languages. He begins the article by explaining that yes, there have been a number of large successful projects developed in functional programming languages. But compared to the number of programmers who work in procedural languages, the number working in functional languages is essentially zero. The reasons he listed fall into eight categories.
- Lack of compatibility with existing code
- Limited library support compared to popular languages
- Lack of portability across operating systems
- Small communities and correspondingly little community support
- Inability to package code well for reuse
- Lack of sophisticated tool support
- Lack of training for new developers in functional programming
- Lack of popularity
Most of these reasons do not apply to Microsoft’s new functional language F# since it is built on top of the .NET framework. For example, F# has access to the enormous Common Language Runtime library and smoothly interoperates with anything developed with .NET. And as far as tool support, Visual Studio will support F# starting with the 2010 release. Even portability is not a barrier: The Mono Project has been quite successful in porting .NET code to non-Microsoft platforms. (Listen to this Hanselminutes interview with Aaron Bockover for an idea how mature Mono is.)
The only issues that may apply to F# are training and popularity. Programmers receive far more training in procedural programming, and the popularity of procedural programming is self-reinforcing. Despite these disadvantages, interest in functional programming in general is growing. And when programmers want to learn a functional programming language, I believe many will choose F#.
It will be interesting to see whether F# catches on. It resolves many of the accidental difficulties of functional programming, but the intrinsic difficulties remain. Functional programming requires a different mindset, one that programmers have been reluctant to adopt. But now programmers have a new incentive to give functional languages a try: multi-core processors.
Individual processor cores are not getting faster, but we’re getting more of them per box. We have to write multi-threaded code to take advantage of extra cores, and multi-threaded programming in procedural languages is hard, beyond the ability of most programmers. Strict functional languages eliminate many of the difficulties with multi-threaded programming, and so it seems likely that at least portions of systems will be written in functional languages.
Related post: Functional in the small, OO in the large
John,
this is very interesting. Can you explain, or point at some article, describing the simplification in multi-threading programming in functional languages?
The core difficulty (no pun intended) with multi-threaded programming is managing shared state, and pure functions can’t step on each other’s state.
Also, functional code doesn’t need to run in sequential order, so code can move around to take advantage of multiple processors. For example, if you have pure functional code f( g(x), h(x) ), a computer could evaluate g(x) and h(x) on separate processors simultaneously without fear that the result would be different than if g(x) and h(x) were evaluated sequentially. With procedural code, there’s always a chance that the evaluation of g(x) would change some state that h(x) depends on. You can write pure functions in a procedural language, but you’re on your honor not to alter any state. With a functional language, you have a compiler to make sure you don’t accidentally break your promises.
Practical functional languages are not completely pure, but they flag impurities so that they’re handled with special care, and that allows them to take liberties with the portions that really are pure.
Clojure is another new language for which many of those points do not apply. It’s a Lisp-like language with a strong emphasis on a functional programming style that is built on top of the JVM. It has an elegant syntax for Java interoperability so existing Java libraries can be used easily. However, it falls short on the “lack of sophisticated tool support” front but this is changing rapidly.
Most interestingly, Clojure was built from the ground up with multi-core programming in mind and a lot of thought has gone into making sure concurrency is easier to do correctly.
This post pretty much steals my exact thoughts.
F# breaks through a lot of the barriers for functional programming. I work in a massively-scaled, highly parallel environment and I’ve been teaching myself F# for the inevitable moment when much of this stuff needs to be re-written. With a large codebase written in C#, knowing that I can “inject” F# where necessary and not have to worry about stupid issues like type compatibility actually opens the door for this stuff happening.
I can’t make any promises of course, I’m not surrounded by people who “think functional”, but LISP had zero chance of being used in this environment where F# has a greater than zero chance. That’s a big win.
and scala too … http://www.scala-lang.org/
f#, clojure, and scala seem to be the potentially successful functional languages, largely because they build on a pre-existing VM ecosystem (CLR or JVM)
F# one of the best languages ever! Can do any stuff in less 100 times less lines than in Java.
I’ve only started to learn F# (after playing with Haskell); and so far I can say that its a very beautiful language!
Don’t still on the fence, dive right in. Learning about foundational programming before coming to F# may help ease the learning curve though.
Insightful observations. However we’re now in 2014 and I get the sense that Scala + JVM currently trump F# + .NET on the popularity stakes. I’m curious as to why you didn’t back Scala.
Well it has been 6.5 years since this blog entry was written, and I just searched for F# programmer openings today on the biggest job board on the web.
For comparison, I currently see 3,650 openings with “C#” in the title, 2,220 openings with “PHP” in the title, 16,783 openings with “Java” in the title, 2,282 openings with “C++” in the title, 2,109 with “Python” in the title…
And how many openings with “F#” in the title?
Just 3.