What is Functional Programming?
The core meaning of the FP paradigm.
Photo by Bozhin Karaivanov under the Unsplash license
In a nutshell:
Functional Programming is a program construction technique that forbids the use of assignment.
And by assignment I mean any form of value mutation.
I prefer to use this definition because is easy to remember, short and concise. If you try to program with that constrain and that constrain only, you will soon find that, as a consequence, all your functions are going to be pure because they cannot have state, they are also going to be referentially transparent because they are pure, and if you keep going you will find yourself reinventing the functional vocabulary: folds, maps, filters, functors, applicatives, monads and so on.
What is state?
When something has the ability to mutate, we say that the thing has an accumulated effect, or identity, or state. Things with state are intractable for the reason that we cannot easily establish equality between them. This problem rapidly acquires philosophical dimensions when those things are us: Am I the same I was yesterday? Nobody knows.
Also a common problem with state is we can no longer share things easily, because we don’t know who is going to change them.
State is also related with time, as soon as you introduce state in your design you are coupling that design’s time with the human time. This is bad because what could be described by some static truth (a velocity function for example) is now blurred by an apparent non determinism that mess up everything. Take for example our own existence, do we have free will or the universe has everything set up for us? These kind of questions will be easier to answer if we could freely move in time as we move in space.
Why do we need state?
The less crucial reason is that:
State gives us the best modularity we can get.
How’s that? Well think about it, you can easily isolate any complex system just by giving it state. Think of a random numbers generator, the client of that system only need to know that the it gives a random number whenever is used, none of the system internals leak outside of it.
Why is it the less crucial one? Because in some places you can mimic the same modularity without state. In programming languages, Haskell is a language that goes pretty far in pushing the state to the boundaries of your system. Let’s see the random numbers generator example in programming languages.
Example with state in JavaScript:
function twoRands() { var a = Math.random(); var b = Math.random(); return [a, b];}there Math.random is a function with state.
Example without state in Haskell:
twoRands :: Random a => Rand (a, a)twoRands = do a <- rand b <- rand return (a, b)there rand is a function without state, but its internals are hidden by Rand (a monad I define as a wrapper of the State monad).
And the more crucial reason is:
We are prisoners of time, and for some problems that concern us we cannot use static truths to solve them, because we can’t possibly know such truths.
Think of concurrency: situations that are inherently non deterministic.
Conclusion
Functional programming is all about static truths such as in Math, is easier to reason about, is tractable, and in a lot of places solves our problems better than imperative solutions. But as in life everything’s not black and white, there are a lot of shades as there are problems that cannot be solved without state, so our goal is to find a balance. For me pure functional languages are the greatest examples of that balance.