One of the major themes of accu2008 was functional programming. That's partly because we deliberately skewed in that direction, inviting Simon Peyton Jones to give a keynote and asking Joe Armstrong to run one of the preconference tutorials, and partly because it reflects current discussion, both within ACCU and much more widely. If you look at some of our regular speakers, many of them of spoken on functional programming topics in the last couple of years so it's a sudden new or expected theme.
At the heart of function programming is purity. A mathematical function
f given an input
x gives a result
y. And that's all. In a functional programming language, a function
y. And that's it. In a more conventional programming language (although I'm slightly uncomfortable with the term "more conventional"), a function
x could produce
y, then if you give
x again it might give you back
a bit of logging,
write something to the screen. And
launch the missiles. Those are, perhaps slightly disparagingly, called the side effects. Pure function programming eschews side effects. Pretty much everything else that's associated with FP stems from that: concurrency, function composition, garbage collection, type inference (whether static or dynamic), and so on.
Of course, functional programming is nothing new, it's history goes back as far as computing itself, and the two languages most discussed currently and represented by their designer/implementors at the conference, Haskell and Erlang, aren't exactly spring chickens. You don't have to be knee deep in spurious parentheses to "be functional" though, many of people routinely use of functional programming languages or functional programming techniques in their everyday work. The often overlook XSLT and XQuery could, I suspect (on no particular evidence), be candidates for the most used functional languages at the moment, although the vast majority of their users wouldn't consider themselves to be "functional programmers". That's if you don't count spreadsheets which, as Simon Peyton Jones pointed out, are functional programming tools. We all nodded and said "ah, yes, of course!", because as soon as he said it we knew it was true, we'd just never considered it in those terms before.
What particularly pleased me was the generally pragmatic approach being advocated. Simon Peyton Jones gave a fantastic, engaging, energetic keynote on Haskell, a language he helps to design and implement, in which he characterised functional languages as safe but useless. If a program has no side effects how do you know it has run? he pondered. More conventional (although I'm uncomfortable with that label) imperative languages are, he suggested, dangerous but useful. Those side effects we try so hard to avoid are actually what we need to do any real work.
In order to become more useful, he argued, functional languages need to be a bit more dangerous, while imperative languages can become safer by becoming more functional. For me, that's the single most useful idea to take away from the conference. It's not necessary to throw away all your existing code and start afresh in some strange new language. Programming in Python or Java or Perl or C++ doesn't make you, as many LISPers in particular like to suggest, a lesser programmer with a smaller brain. Simply by examining your practice, and perhaps taking on some FP ideas, maybe formalising slightly something you already do, you can become an even better programmer.
Assign-only programming is one idea, which I first heard about from Russel Winder. He suggests that a variable should be assigned once, and then never changed. I think he developed this idea while teaching his students Java, to great effect. Immutable variables sounds like a bit of a contradiction, but matches the concept of a variable in mathematics. A variable may take many values, but at any given time it has a single, unchanging, value. Since FP languages use the mathematical notion of a function, they also adopt the mathematical notion of a variable. Assign-only brings that idea into imperative languages. Obviously it needs a bit of discipline because your compiler/interpreter is less able to help you (unless it supports the notion of const, say), but it's a relatively simple and, Russel argues, productive thing to try.
Peyton Jones advocates a strong differentiation of the pure code and the effects causing code. Rather that have effects throughout your program, they should be isolated. We often talk about seperation of concerns, partitioning, and so on, and what he suggested made a lot of intuitive sense. So much so, I'm slightly surprised that I don't recall having heard it suggested in quite those terms before. Haskell actually puts this idea right into its type system. Effects-causing functions in Haskell are called Monads, and there's some fierce mathematics behind them. Peyton Jones glossed over that, noting that he wished they had been called "warm fluffy things". A warm fluffy thing carries a type annotation, and (I think this is correct) cannot be called from a pure function. Since a pure function that called an impure one would no longer be pure, you can see why this makes sense. It's analogous to C++'s notion of
const method is stating that it won't change an object's internal state, and so a
const member function can't call non-
const member functions . This separation also fits will with Russel's assign-only idea.
There's more to be investigated here, particularly around my favourite little hobby-horses of pipelining, iteration, and algorithms. Unfortunately (or perhaps fortunately) my train's about to arrive and my batteries running flat, so I'll have to come back to it another time, if I ever get my thoughts sufficiently lined up. (The EEE I've been typing this on is fab, by the way.)
 - Let's leave aside
const_cast please. It really isn't the type system get out of jail free card, nor is it the worm at the heart of the apple. The notion const-ness is a good and useful idea, a powerful one even. I've heard many people lament (indeed I've done it myself) the lack of const in Java and C#, Python too. Recently, I've heard it argued that C++ free functions, not just member functions, should be const-volatile qualifiable. That is an interesting idea. [back]