Why Functional Programming?

In this post, I would like to share why I think the functional paradigm is such a big deal, and why it is worthwhile to learn about it, no matter which technology you are using.

Functional Programming Roots

Functional Programming (FP) is deeply rooted in maths, and is intimidating because of that. But I think we underestimate the value of a mathematical approach of software: it allows to express complex problems with a succession of simple statements. When we translate this to IT, the point is to compose complexity to keep software systems predictable, no matter how big they are.

How mathematics works

Mathematics always follow the same pattern. They define something in a general way, like a polygon: “a polygon is a plane figure that is bounded by a finite chain of straight line segments closing in a loop to form a closed polygonal chain”. Then by applying specific laws, they are able to define more specific things: “A triangle is a polygon with three edges and three vertices”. And by adding more laws, we obtain even more specific things, like an equilateral triangle “An equilateral triangle has all sides the same length”. As you will see, FP design patterns can be explained in the same way: we will use something general, and because we will add some laws, it will define a more specific concept. Note that “A monad is just a monoid in the category of endofunctors” follows this pattern as well. It seems complicated because it uses other concepts we’re not familiar with.

Don’t be scared to learn the symbols

Maths are often intimidating due to complex words and abstract symbols. Learning them is a first step to demystify it. Here are some symbols often used to explain FP concepts:

The mathematical notation y=f(x) means for x, the relation f will produce the output y. f: a->b means for an input a, the relation f will produce an output b. We usually use this notation in FP. Of course we need to define the set for a  and b (integers, positive integers, real numbers, string…). The set of a is called the domain of f, and the set of b is called the codomain of f.

g°f means the composition of g and f, in other word the application of f,then g.

f ≡ g means that f is equivalent to g.

Software predictability

In a pure FP program, f: a->b is always true. Functions are pure, which means they will always produce the same output for the same input, no matter when the function is called. In our industry, because states can mutate over time, we build software where it’s false. If f has side effects, or if anyone can mutate a or b, we can no longer predict the output of f, because it is context dependent. It adds a lot of complexity in our code. Building a program by composing pure function can remove this complexity.

Why Function Composition?

Functional programming is all about function composition. If I have 2 function f:a->b and g: b->c, I want the composition g°f : a->c. The composition of simple functions allows to build services. The composition of services can manage use cases. And a composition of uses cases is an application.

Wrap up

Don’t be scared by mathematical symbols, and remember that if we compose pure functions by respecting some mathematical laws, we’ll be able to build a predictable complex software. It is certainly something that has some interest, isn’t it?