We already know one reason why functional programming is crazy: Functional programs can’t really do anything, since they can’t have side effects. As Simon Peyton Jones, a well-known functional programmer, likes to say, “All you can do without side effects is push a button and watch the box get hot for a while.” (Which isn’t technically true, since even the box getting hot is a side effect.)

We’ve seen that we can work around this limitation of functional programming by adding a dirty section to our programs, which is kept separate from the rest of the code and contains all our code that is imperative and not in the functional style. However, recall the problem with the functional style: It can cause code to be extremely inefficient.

Performance has always been a huge concern with functional programs. Having to write code that isn’t allowed to mutate the value of existing variables, but only create new variables, can lead to a huge amount of memory copying and memory allocation, which can slow programs down to a crawl. One way to mitigate this copying and allocation is by using shared structures between different pieces of data in our programs.

Nonetheless, code written in the functional style has other properties that affect performance. For instance, functional code uses a lot of recursion, instead of looping. Using recursion causes the Lisp compiler/interpreter to put a lot of items on the program stack, which can be very slow.

Fortunately, functional programmers have developed optimization techniques that can solve the vast majority of performance problems. These include memoization, tail call optimization, lazy evaluation, and higher-order programming, which we’ll cover in the next few chapters. Using these techniques and others, an experienced functional programmer can write code that is usually comparable in performance to code written in any other style.

However, some types of programs just can’t be written in a purely functional way. For instance, you probably wouldn’t write something like a full-on Oracle-style relational database system in a functional style. Yet, smaller, memory-resident database systems may be able to use purely functional techniques (an example is the HAppS-IxSet available to Haskell programmers at http://happs.org/). So there is really no hard limit as to when functional programming can be used.