Unless you've been living under a rock, you know functional programming is all the rage among the so-called alpha geeks. Perhaps you already use a functional programming language. If you use a more conventional language like Java or C#, you're probably aware it has functional programming features in store. While this brave new world is upon us, and before we take things too far, it might be a good time to pause and reflect on the appropriateness of functional programming for everyday application development.
What is functional programming? The simple answer: Everything is a mathematical function. Functional programming languages can have objects, but generally those objects are immutable -- either arguments or return values to functions. There are no for/next loops, as those imply state changes. Instead, that type of looping is performed with recursion and by passing functions as arguments.
[ Andrew Oliver compares Ruby, Clojure, and Ceylon, which share the same goal, but reach varying results. | Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
What is a functional programming language? The answer to that question is more complicated and subject to seemingly endless debate. Some languages attempt to box you into the functional programming style, while others encourage but don't force the issue. Then there are the more traditional imperative languages that allow you to program in the functional style. Indeed, people are hard at work adding support for functional programming constructs to Java and C#.
The case for functional
Proponents often argue that functional programming will lead to more efficient software, while opponents argue the reverse is true. I find both claims equally doubtful. I could easily be convinced that functional programming will make writing compiler optimizers more difficult or that the JIT compiler for functional code will be slower than the equivalent compiler for traditional code. There are close mappings between imperative programming languages and the underlying hardware support, but these don't exist for functional languages. As a result, the compiler for a functional language has to work harder.
However, a good optimizer should be able to translate a functional programming closure, tail call, or lambda expression into the equivalent loop or other expression in a traditional language. It may require more work. If you're up for a good 1,600 pages of reading on the subject, I recommend "Optimizing Compilers for Modern Architectures: A Dependence-based Approach" and "Advanced Compiler Design and Implementation." Alternatively, you can prove this to yourself with GCC or any compiler that has multiple front ends and can generate the assembler.
The better argument for functional programming is that, in modern applications involving highly concurrent computing on multicore machines, state is the problem. All imperative languages, including object-oriented languages, involve multiple threads changing the shared state of objects. This is where deadlocks, stack traces, and low-level processor cache misses all take place. If there is no state, there is no problem.