I don’t often dedicate a blog entry to just a link, but this one is important. Important, that is, if you’re a computer programmer; in particular a programmer who needs to make code run faster on existing real-world hardware. Which is a minority of a minority, since it excludes most Webfolk whose servers are fast enough and clients are running 90% idle time. But that minority really needs to be thinking about Functional Programming, and if you’re not 100% sure you know what that means, you should drop everything and go read “Uncle Bob” Martin’s Functional Programming Basics.
It’s the best short explanation of what FP is about, and why it’s important, that I’ve ever read anywhere. So even if you do grok FP, you should probably go read it anyhow, because it may equip you a little better for the tricky task of explaining the goodness.
I dedicated a couple of years of my life to this stuff when I was at Sun; scan the Concurrency tag here for the findings.
I’ve got little two gripes with Uncle Bob’s presentation here, which don’t detract in the slightest from its fundamental importance:
His use of the nifty Clojure
(integers)function. I think that when you’re introducing new material to illustrate something particularly wonderful, in this case the no-assignments magic of FP, it’s best to avoid clouding the picture with other flavors of magic, in this case an object that cleverly pretends to be infinite in size but is perfectly useful in finite-world practice. For example, Ruby’s1.upto(25).mapis way less spooky.It’s in LISP. Which has had fifty-five freaking years to catch on and become mainstream, and if it were going to, it would have. Yes, illustrating FP with somewhat-more-mainstream technology is more work, but the work is probably worthwhile.
The “Java Moment” · My work at Sun was based on the premise that FP in the 21st century is like Object-Orientation in the eighties: Potentially hugely useful, but not really accessible to mainstream app builders. Java came along and made O-O mainstream, with a clever combination of familiar idioms and decent libraries.
I believed (and believe) that the conditions are right for something else to come along and do for FP what Java did for O-O. Both Clojure and Scala are consciously trying to do this, and not coincidentally, on the Java platform. But I don’t think either quite hits the mark; there’s still a big place in the ecosystem waiting to be occupied.
Contributions
Comment feed for ongoing:
From: Jeremy Dunck (Jan 03 2013, at 08:33)
I understand your skepticism of lisp catching on, but you could make the same argument for FP itself. I'm not sure it's a winning argument. Yes, let's have more useful FPs, and maybe let them be on the JVM, but I think a lisp on the JVM is a new thing and worth attention despite the parens.
[link]
From: Jordan Henderson (Jan 03 2013, at 08:44)
With virtualization and the cloud, the percentage of programmers who should care about performance should increase markedly.
If your server is sitting there at 90% idle, provision a much smaller virtual server to that function and use the other 90% for other business needs. If you only have need for 10% of a small server, move the function to the cloud and provision a tiny server there.
[link]
From: Cedric (Jan 03 2013, at 08:59)
Mmmh... I have a slightly more cynical view on Robert's description of functional programming, which I expressed here: http://beust.com/weblog/2013/01/02/no-silver-bullet-reloaded/
FP is important but I'm not sure that Robert really understands why.
[link]
From: John Cowan (Jan 03 2013, at 09:26)
Dude, it's the rest of the world that's still trying to catch up with Lisp. Lispers were writing good code that still runs today when you and I were in diapers. See http://recycledknowledge.blogspot.com/2011/11/john-mccarthy-inventor-of-lisp-died.html.
But you know that, I'm just tweaking your chain here.
[link]
From: Corneil du Plessis (Jan 03 2013, at 10:55)
I agree with your assessment of Uncle Bob's article.
FP is a part of the solution in that it is a lot easier to optimize code without side-effects.
The actor programming model is another part of the solution since the side effects are messages. Messages can be queued, transported or persisted. In the actor model most message travel directly from source to destination.
The LMAX architecture is an example of what is possible.
[link]
From: Michel Alexandre Salim (Jan 03 2013, at 19:37)
I happen to think FP will never be fully mainstream as well, but its features are likely to trickle down into more mainstream languages -- after all, pure OO languages don't do spectacularly well either (compare the adoption of Smalltalk to, say, C++ and Java).
C# already has anonymous functions for several years -- it's quite a shame that, for all the high-profile innovations by third-party languages on the JVM (similar languages exist on the .NET side, but apart from Microsoft-sponsored F# they are more esoteric than Clojure and Scala), Java-the-language is lagging more and more behind. We're finally being promised lambda yet again... sigh.
[link]
From: Paul Baclace (Jan 04 2013, at 14:54)
Corneil du Plessis: Thanks for the LMAX pointer. It's nice to know that queue latency for SEDA architectures in Java can be 128ns or less 99% of the time at 10M messages per second per GHz.
[link]
From: Anton McConville (Jan 05 2013, at 17:45)
Tim, or others, do you have an opinion on style of JavaScript programming - I like the style ( for big projects ) that uses JS Prototypes to make 'classes' that contain functions, and sometimes templates. Some of my team on the other hand like ( what I consider more 'C' style ) libraries of functions that dangle freely.
What's the wisdom with functional or OO programming for JS? Am I ( wrongly ) stuck in OO type ways?
I was hoping this post of yours was coincidentally probing into that.
[link]
From: Tired of Java (Jan 05 2013, at 22:43)
Tim, were you on the team with James Gosling that helped make Java a big fat overwhelming beast that required a bookshelf full of fatter-than-yellow-pages-phoneboooks Addison-Wesley books just to look up some overly verbose API in EJB? Sun put out an enormous amount of marketing and PR to basically brute force thrust Java onto the world (even though NeXT's choice of Objective-C didn't get nearly the lion's share of attention as OOP was coming into its own). Is this the same Tim Bray who has been singing the praises of Ruby in recent years yet can not convince Google and Andy Rubin's team to bring Ruby to Android? No offense to Bob Martin, but why you linked to him instead of Dean Wampler's December 2012 presentation notes in London "Beyond MapReduce" which has some great slides about where FP is contextually important, is beyond me.
[link]
From: taj (Jan 19 2013, at 07:33)
"upto" may be less spooky, but AFAIK it's not lazy, and laziness is as important a feature of FP as tail calls are.
[link]
From: Matthew Huntbach (Feb 03 2013, at 16:40)
My first job, back in 1981, was as a research assistant on a project called "ZAPP" meaning "Zero Assignment Parallel Processor". It was about mapping functional programming onto a parallel architecture. Yes, back then we were told "it’s almost certainly true that functional programming is the next big thing", and for much the same reason as now - that parallel architectures were going to force a switch to a new programming paradigm which didn't have the inherent sequential nature of conventional programming languages.
However, when it's now being pushed by people with real world credibility rather than academics, one has to take notice. It looks to me like a combination of factors have brought this about:
1) Physics has finally forced us to the point where we can't just get more performance from more efficient single processors - what was predicted 30 years ago, finally has become true, we are going parallel.
2) The Java Virtual Machine makes it much easier to introduce a new programming language than in the days when you'd have to do it all from scratch. Now you can just link into Java to get all the boring support stuff that a new language needs adding to its core to be of practical use.
3) Object oriented programming had to happen first. The OOP paradigm worked much better to take programming to a more abstract level than functional programming because it fitted with the rise of GUI and the concept of programming as modelling. FP needed to come in on top of that. The modern FP systems are able to interact with objects in a practical way, while older FP systems could not.
[link]