Functional Programming Wisdom

Search

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’s 1.upto(25).map is
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.

Updated: 2013/01/03

Contributions

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.

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.

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.

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.

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?

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.

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.