I’ve just stumbled across the Functional Programming For The Rest of Us article at www.defmacro.org, and found it a very timely reminder of the basics of Functional Programming, and both interesting and provocative.
I’d taken a short course on FP as part of my computer science degree about a decade ago, but haven’t really looked at it since. The course was straightforward enough, and it was even suggested that I might want to join the research group after finishing my degree. But the course didn’t cover the mathematical background to the extent I’d have liked, nor any specific “real” language (it was based on taking us through the development of a made-up but very LISP-like language). I’d read a couple of extra text books to try and fill-in the gaps, but never really felt like I’d got a solid grip on either FP’s theoretical foundations or its practical application. Most of all, I never reached the point where I could see how it could be used as a general-purpose approach for “real-world” applications, other than in particular domains or for specific components.
With all the current talk of adding closures to Java and various discussions of continuations and other such FP terms, I was starting to feel that it might be time to dust off the old text books and revisit the fundamentals of FP. At the very least this would hopefully give me a more solid basis for understanding the “closure” discussions and any support for closures that eventually gets added into Java.
So happening to come across the article was very timely for me. It struck just about the right note as both a beginner’s overview of FP and a reminder of why it both does and doesn’t appeal to me. I can definitely recommend it to anyone that doesn’t know FP and is wondering what this stuff is all about (though personally I’d say don’t bother with the “Walk in the Park” section at the beginning).
Especially interesting was the reminder that, at least in theory, FP and its “no side-effects” approach ought to greatly simplify the documentation and testing of code. I’ve heard this before, but don’t think I’d fully appreciated it at the time. Over the last couple of years I’ve found that I spend far more time writing Javadoc to specify and document code than I do writing the code itself. And I spend even more time than that writing tests for the code, which is often rather harder work than I’d like it to be.
So in the context of my current work, some of the claimed benefits of FP suddenly ring lots of bells. Any approach that might potentially simplify these aspects of development certainly seems worth understanding. Of course, I’m not so naive as to think this actually solves the problem, or that I should just switch over to using some FP language for everything, just that it might be worth looking into, and might then be worth bearing in mind when looking for improvements or an eventual solution.
Less convincing in the article is the discussion of how a “sequence” of processing can be imposed. It all sounds clever enough, but in the end we’re talking about something that in imperative programming is absolutely intrinsic and appears trivial (though it actually isn’t – think threading, memory models etc). Maybe I’ve misunderstood the problem, as it doesn’t seem that difficult even in FP. But the article gives the impression that in principle sequence isn’t that important in FP, then by the time it’s recognised as something that actually does have to be catered for, we’re in the FP world with its own distinct terminology, ideas and research. The eventual solution is then couched in those terms, and at that point it sounds like a really clever solution to a very difficult problem. If all you’ve got is a hammer, not only does everything look like a nail, but a screw looks like an extremely complicated nail that needs really careful, expert hammering. (By the way, I think this is a fairly common anti-pattern. I’ve seen it over and over again, at all scales: for example when personal computers first appeared into a mainframe-dominated world, and most of the people involved started inventing everything from scratch – the whole industry seemed to initially ignore or deliberately avoid, but then eventually had to tackle, all the issues such as concurrency, security, configuration, change-control etc that had long ago been tackled in the mainframe world and were actually quite well understood).
Overall, I’ve always regarded FP as academically interesting but I’ve not yet been convinced that it can be a practical approach for anything other than specialised uses. After all, its fundamental difference from traditional imperative programming seems to be “no side-effects” and no dependence on non-argument state, but most real-world requirements seem to be all about side-effects and “external” state: database updates (with data that is of broader interest and value than just being part of one particular application), interactions with people (whose lives are absolutely brimming with “state”), interactions with other systems etc. Just how would one use FP to write a word-processor, say, or an operating system?
I guess one could regard the whole of a system’s state as a single thing and have functions that operate on such values, or could formulate the system as an ongoing calculation that never actually ends and where the state of the ongoing calculation is of interest. But it’s hard to imagine how that can be done without expanding the scope of a system until it encompasses absolutely everything; or without encountering all the problems of state and side-effects but just hidden under different terminology (and made all the more complex by pretending they don’t exist). It’s also hard to see how you’d handle any discussion of requirements and other such communication with users, customers etc – the FP approach just seems too far removed from any non-practicioner’s view of the world.
No doubt FP has solutions to some or all of these issues, or at least some kind of workable compromises. Or maybe it really is only suitable for particular types of problems. Or maybe it’s just me being an ignorant, dyed-in-the-wool imperative guy, who simply doesn’t get it yet.
Anyway, now definitely seems the right time to take a look at FP again, and the article has re-kindled my curiosity. So I’m going to dig out one of my old textbooks on FP for some bedtime reading, and see how I get on with it. If I somehow find time, I might take a quick look at a “modern” FP language as well, and see what kind of things are being done with it.