Bugs in computer programs usually happen because, under certain circumstances, the code behaves in ways the programmer didn’t expect when the code was written. In functional programming, the behavior of your functions depends on one and only one thing: the arguments explicitly passed into the function. This makes it much easier for a programmer to appreciate all the circumstances a program could possibly encounter, including circumstances that could lead to errors.

Writing functions that depend on only their arguments for their behavior also makes bugs easy to duplicate. If you call a function with the same data passed in through its arguments, it should do the same exact thing every time. This is the property we called referential transparency.

It turns out a lot of the work in run-of-the-mill computer programs involves creating, initializing, and updating variables. Functional programs don’t do any of this. As we discussed earlier, functional programs make use of higher-order functions, which don’t require us to create tons of temporary variables in our code, and that makes our code more compact.

The biggest advantage of functional programming is that it brings all of computer programming back to the domain of mathematics. It wouldn’t make sense for a math equation to pop up a dialog box or write to the hard drive. It can be argued that if we get our computer code back to this same level of purity, it will be far more elegant. Additionally, if our code is closer to the world of mathematics, we may be able to use tools in mathematics to write better computer code.

In fact, a lot of research continues to be done in using mathematical proofs to check for the correctness of functional computer programs. Although this research still isn’t to the point where a practical programmer would use such techniques, they may be more common in the future. And, almost certainly, a functional programming style will be essential in making correctness proofs on your code possible.