Functional programming FAQ

What is functional programming?

Functional programming (FP) is a powerful approach to computer programming that complements object-oriented programming, and in some situations is a superior alternative. Functional programming relies heavily on the use of functions as objects that can be passed around within a program, in the same way that traditional languages pass variables and data objects. Functional programming has been around for a long time. It traces its roots back to mathematical theories that predate the computer industry itself.

Why don't more people use FP already?

Until the last decade or so, the speed and amount of memory in the computer were important limiting factors in all but the most lavishly funded projects. It was essential that the programmer tell the computer exactly what to do at every step, in order to avoid wasting any precious processor time or memory space. This gave rise to the traditional method of programming, which is called "procedural" or "imperative" programming, because the programmer issues commands (imperative statements) to the computer indicating what procedures it should execute.

Since computers were so small back then, almost all programming languages were procedural languages. And because of both these things, essentially all students of computer programming learned to program in the procedural style. This became so common that most people now equate programming with the process of issuing direct commands to the computer. Many people have never heard of any other kind of programming.

What are the benefits of FP?

Over the decades, Moore's Law—that computer processor speeds double every year or so—has brought us processing power so plentiful that today's inexpensive PC dwarfs the power of the mainframes that were available just a few decades ago. Today's computers are able to run bigger, more complex programs in a heartbeat.

What has not doubled in power every year is the programmer. The personal, intellectual resources of the programmer sitting down today in front of a modern, high-powered computer are comparable to those of the pioneers of 50 years ago. Meanwhile, the programs we write have gotten bigger and more complex. The result has been a shift in the software industry, to a situation where the programmer rather than the computer is the limiting factor. This is demonstrated by all the difficulties experienced in large projects because program bugs are so hard to track down and fix, and the source code is so big it's very hard to make significant changes.

This does not have to be the case as much as it currently is. The typical programmer writing code in an object-oriented language like Java or C++ spends a lot of time writing type declarations and other superfluous code that's not necessary with today's dynamically-typed or type-inferring compilers. A million-line application in Java or C++ can be boiled down to a couple hundred thousand lines in powerful functional languages such as Lisp or OCaml. With less source code to create and hide bugs, fewer bugs crop up, and the ones that do occur are easier to find. Project teams can be smaller, reducing the amount of communication—and miscommunication—overhead drastically.

Testing is made easier by the structure of functional programs. Many object-oriented design patterns are hand-coded implementations of functional programming.

Functional programming helps to make multithreading easier. This is increasingly important with today's multicore processors.

There are programmers using functional programming to deal with the "object-relational impedance mismatch". This is a fancy way of saying that OOP isn't all that great for database programming, and that functional programming works better.

Is FP a Silver Bullet?

No. Functional programming will not save a programmer or a project or a company from poor planning or organization, or lack of ability or training. Functional programming is a powerful tool that can make competent, well-trained programmers exceedingly productive, given an environment that's generally supportive of productivity. It can not compensate for a distracting, disorganized environment, or programmers who simply haven't learned the methods of professional software development.

What about OOP? What about code generators and refactoring tools?

"There is a kind of mania for object-oriented programming at the moment, but some of the smartest programmers I know are some of the least excited about it."
Paul Graham, Why Arc Isn't Especially Object-Oriented

Most people understand the idea of an object without too much trouble. We deal with objects all the time in other areas of life, so the conceptual leap to object-oriented programming is manageable. Functions, on the other hand, are more abstract, so they require a little more training before the programmer knows how and why to use them.

But the end result is that functional programming allows consolidation of the source code in ways that are not possible or much more difficult using only OOP. Code-manipulation tools are made to solve problems that functional programming languages don't have. Ultimately, they're less effective.

But if FP is so abstract, is it worth the effort?

Judging from some spectacular recent failures in Enterprise software development, I would say code consolidation is indispensible to the larger, more complex projects, and functional programming is one of the best ways to do that. Paul Graham, one of the leading voices in the software industry today, relies on functional programming much more than on object-oriented programming. Graham frequently mentions using closures, which are one of the basic tools of functional programming. In the late 1990s, Graham used Common Lisp to write code that Yahoo! later purchased for $50M. Lisp is a highly expressive language with many features of functional programming. Even though Common Lisp has one of the most powerful object systems available, Graham rarely feels a need to use it, simply because he doesn't use OOP much.