No future for functional programming in 2008 – Scala, F# and Nu
On Lambda the ultimte there is a recent post with a language prediction for 2008, which mainly predicts the rise of functional programming and the rise of Scala in particular: “My prediction is a little bit more conservative, but I predict Scala will gain momentum, and at least one high visibility project will use Scala”. Brandon chimes in with “The most important thing to emerge from the discussion is the larger role functional programming will play. It seems like a safe bet.” A safe bet, really? I more sceptical, as written in my post about Qi4j and Scala.
The blogosphere is full of functional programming language advocates and the coming rise of functional programming in application development. But has anything changed since Lisp was invented in 1958? Functional programming languages have existed for more than 50 years now, and didn’t make any inroads into application development. What happend to the acclaimed golden age of functional programing, about which Peter Christensen writes? Will it come back? I dispute in a comment to that post that there ever was a golden age of functional programming, it was a fringe language from the beginning. There was a golden age of Fortran.
John McCarthy – no not THAT McCarthy – invented Lisp back in 1958. From there functional programming gained much appeal to programmers because of it’s clean and consistent style. Everything in Lisp is a list. Even the program itself. Because good programmers have a feel for aesthetics in programming style, they have a warm feeling for Lisp. Functional programming is also a powerful tool for software development. And developers like power. As Paul Graham writes in “Revenge of the Nerds” about power in languages with the aim to praise Lisp:
As an illustration of what I mean about the relative power of programming languages, consider the following problem. We want to write a function that generates accumulators– a function that takes a number n, and returns a function that takes another number i and returns n incremented by i.
He cites an example in Lisp, that implements an accumulator in a nice and pure way:
(defun foo (n) (lambda (i) (incf n i)))
Functional languages excel at mathematical and list processing problems. Most problems to solve in the enterprise are of a different type though. When moving to real problems then, functional programming languages get ugly as an ugly duck. With no swan in sight. Looking at examples from Implementing a blog in Common Lisp: Part 1, we see how ugly it can get. In Java land people a frustrated about XML, but see the brace chaos in Lisp, just to open a database:
; Open the store where our data is stored
(defvar *elephant-store*
(open-store '(:clsql (:sqlite3 "/tmp/blog.db"))))
And defining a blog domain object doesn’t look very readable either:
(defclass blog-post ()
((title :initarg :title
:accessor title)
(body :initarg :body
:accessor body)
(timestamp :initarg :timestamp
:accessor timestamp
:initform (get-universal-time)))
(:metaclass persistent-metaclass))
compared to a Groovy example:
@Entity
class BlogPost {
String title
String body
TimeStamp timeStamp = now
}
or a Java one in Qi4j:
public class BlogPost {
Property<String> title;
Property<String> body;
Property<TimeStamp> timeStamp = now();
}
Another example from nu, the rising functional star for Macos X. This time with the famous Currency converter example which creates a window:
(set @window ((NSWindow alloc)
initWithContentRect:'(125 513 383 175)
styleMask:(+ NSTitledWindowMask NSClosableWindowMask NSMiniaturizableWindowMask)
backing:NSBackingStoreBuffered
defer:0))
(@window setTitle:"Currency Converter")
With an equivalent example in Groovy to build a Swing UI:
def frame =
swing.frame(title:'Frame', size:[300,300]) {
borderLayout()
textlabel = label(text:"Clicked ${count} time(s).",
constraints: BorderLayout.NORTH)
button(text:'Click Me',
actionPerformed: {count++; textlabel.text = "Clicked ${count} time(s)."; println "clicked"},
constraints:BorderLayout.SOUTH)
}
Mostly equivalent with the Groovy example which is still slightly easier to read and understand, even by someone who doesn’t know Groovy. Mainly because Groovy is more expressive and not everything has to be pressed into a list (though the nu example contains more than lists as nu aims for object orientation).
In a discussion about Arc, a functional language, stevecooperorg writes about Lisp and the use of Emacs/Slime:
I’d like to write the next Viaweb, and I’d like to write it in Lisp. But if the basic language is inviting, the rest of the environment is sorta hostile; a shangri-la in a swamp.
That’s another problem of most fringe languages. People – the enterprise? – need to know too much beside the language. Using a fringe editor which most people abandoned in the 80s and “a decent knowledge of system administration” is too high a barrier.
Power is a good thing it seems. From my experience most developers can’t handle power. They misuse it. If your development team is less than 5 developers the chance is high that all of them are alpha developers. And your interviewing process was rigorous of course. Above ten and the chances are high that there won’t be only alpha coders. Power is a dangerous feature of a language then.
Do powerful languages scale? Do dynamical type reference languages, which most functional languages are, scale? Scaling in time and organisation? Does it scale from 6 months to 10 years and does it scale from 2 people to 50? I have my doubts for years and still ask anyone to show me how those languages scale. I really want to know. Others too. Manageability writes about Python and Chandler:
What I find interesting is that Chandler started as a Python project with bold claims such as “Python programs are both concise and readable, this makes it excellent for rapid development by a distributed team” and “Chandler design goals: … design a platform that supports an extensible modular architecture”. I was hoping to see this project as a testament to Python’s viability to large scale development.
The jury is still out, but I wouldn’t bet on scalability. As a project manager during the 90s two of my projects didn’t scale and had to be rewritten, one in Python and one in Perl. But it could just be me.
What happend to Haskell and Erlang, the functional hypes of 2006 and 2007? The Blogosphere has mainly lost interest in those lately. Scala and F# seem to be en vogue in our days. Arc perhaps is next in line to be en vogue. Certainly after Scala, which is next the next thing after Java as Bruce Eckel claims. What has changed from the days of Lisp 50 years ago I asked. Scala and F# are different from Haskell, Erlang – and Lisp. They build on an a proven plattform, on libraries that people know. Scala mostly on the JDK and Java ecosphere, F# on the Microsoft universe and .NET. They both are the most promising functional candidates when it gets to momentum. The transit for C# and Java developers seems to be easiest compared to other languages. Will that be enough for them breaking through into the mainstream?
Will the release of Arc, written as a pet project by Paul Graham the greatest functional rock star, help with functional programming? No, certainly not. Arc lost it’s appeal even before it was released. While waiting for the Arc blessing, people moved on to Scala, Erlang or F#.
Don’t kid yourself. There will be no rise for application and especially enterprise development in functional programming (See what happens when you use a Perl script to do your billing, not that I haven’t screwed up in the past with Java ;-) Which doesn’t mean to stop using functional programming languages. It’s fun, keep going.
Thanks for listening.
You can leave a Reply here. Of course, you should follow me on twitter here.
Hi Stephan!
I stumpled upon your blog recently. How small the world is. I’m working as a .NET developer freelancer these days, so I’m not that much into Java , but I share your interest in architecture, dynamic languages etc.
So, I think you’re right that pure functional languages are not particularly suited for real world issues. But do you realize that the new version of C# (and even VB, ugh) has a full blown Haskell machinery built in called LINQ?
So, at least some functional language concepts have definitely made it into the (.NET) mainstream already.
One of the benefits of functional languages (or functional constructs) is that sideeffects are under control. IMO that’s becoming important because it allows to scale execution to multicore easily.
Erlang seems to gain some popularity recently because of its additional support for concurrency. Some people even think it will be the next Ruby (http://www.pragprog.com/titles/jaerlang).
cheers
Florian