What Is Functional Programming + Why It (could) Make You A Better Programmer?

What is a programming style?

When a programmer sits down to start a new project they have a few decisions to make, the chief one being how they should write the program. Coding is a lot more creative than it is given credit for. Programs can be written in many different languages and styles (known as Paradigms) from novel length scripts to one-liners as comprehensible as wingdings.

This is the main reason for debate in programming circles. There is no one answer. There are many ways of solving problems and ultimately as long as the project is completed, it doesn’t matter how it was done. The choice of style is based on a programmer’s experience and the details of the project.

The only good project is a completed project.

Functional Programming (FP) is one of these styles. More common styles are Imperative Programming and Object Oriented Programming. These styles lay out a set of guidelines you have to follow. If a programming language allows you to follow [x] style guidelines, that language is said to be a [x] style language. Languages can include multiple styles (e.g. Python) or focus only on one style, known as pure languages. However, these guidelines are not generally enforced (only certain pure languages enforce) leaving it up to the discipline of the programmer to abide by them, similar to a writer’s responsibility for good grammar.

What is Functional Programming?

Analogy time: Imagine the inside of a large factory space. Big, completely empty, sunlight streaming in through tall windows. This space is going to be used to make cars. Specifically Tesla cars.

Because Tesla cars are cool

The factory overseer (our stand in for the programmer) realizes there are several options for laying out the factory machines and workers.

An Imperative overseer would produce the car using a factory line. The components start at one end of the line and a car comes out the other. Along the way, workers carry out each construction step. The next worker is reliant on, and waiting for, the previous worker to finish up. The slowly growing car progresses along the line as the workers finish. With smaller projects, this is fine, but with larger projects this factory line becomes slow and wastes a lot of the worker’s time.

An Object Oriented overseer would split the workers into groups and have the car be built on a central stage. Each group is responsible for a component of the car. One group does the wheels, another does the undercarriage, another the paint. This method of working does mean less time waiting. While one worker puts the wheels on, paint can still be mixed and metal welded. It also means the source of errors can be located more easily. You don’t have to stop the factory line and check each worker’s output. If the spokes are crooked, you check the wheel group, headlamp failing, check the electrics group etc. However the workers are still reliant on each other to a degree, shouting across the factory floor. They need to know the current state of the car, after all you can’t apply the paint until the chassis is on.

A Functional overseer would split the factory floor into soundproof rooms connected by conveyor belts. Workers in one room are completely unaware of the rest of the floor. They receive components at one end and they feed the result out the other end. The workers don’t have to be aware of the changing state of the car. They are only aware of what’s happening in the local vicinity. They take pride in producing one thing well, no side projects or alterations, just the vanilla product. They never get to see the finished car. Error sourcing is even easier with such a regimented and simple task. An overseer could check errors just by counting the number of rooms outputting correctly. Additionally, a new overseer could visit and be able to understand the purpose of each room, and flow of the factory floor, without any explanation.

This is one of the reasons why academics love functional programming. They can conduct experiments in each of the rooms, treating each as a testing environment, with no confounding factors. They can work towards causation rather than correlation.

Why should you use it?

Greater Productivity

The functional programming style produces shorter programs in a quicker time, due to:

Greater Modularity

Building a factory floor of segregated rooms requires splitting the car-making process into small and simple pieces. This makes it faster and easier to create the rooms, and easier to have another overseer check the reasoning behind room choice and placement. And due to each rooms singular use, they can be reused easily in later projects.

Easier Testing

When a room performs one function, and produces one vanilla output, it becomes trivial to test whether this output is the same as previous outputs.

Easier Debugging

As each room only receives the input it requires, the number of other outputs it depends on is smaller. When there are only a few paths to trace back along, bugs are located faster.

Specflow. Not a Functional (C#) Project. Good luck finding an error in there.

TickSpeck. Equivalent Functional (F#) Project. Much simpler dependencies.

It's Future Ready

Parallel Programming

As CPU speeds start to flatten out, programs will have to be distributed across multiple CPUs (or CPUs with multiple cores) to keep increasing their speed. The modularisation and lack of communication across the factory floor mean that there is very little interference, something which otherwise prevents CPUs from working well together.

Asynchronous Programming

As the number of data sources, and amount of online hosting (e.g. Internet of Things connected devices, accessible APIs, and cloud-hosted databases), increases the chance of a long wait time for an input will increase. The FP style of composition means that this wait time doesn’t act as a bottleneck. While a room waits for input, the rest can function as per normal building components for the next car. The delayed room then becomes the final step in the process.

It's Good For you

As a programmer

Learning a new paradigm will make you better at what you do. It gives you a new tool to work with and a new perspective, which can help you make you better understand the nuances of styles and languages. And being more productive will allow you more time to work on other things, allowing you to develop in other areas. As with any skill, continuing to challenge yourself is the only way to grow as a programmer.

[people] cannot understand the perfection and imperfections of his chosen art if he cannot see the value in other arts … To just study the sword will make you narrow-minded and will not permit you to grow outward.

Miyamoto Musashi — 17th Century Samurai. Author of The Book of Five Rings

As a person

Being more productive will help reduce stress and pressure at work. It will allow you more free time, which can be spent on things that make you happy. Continuing to learn is also good for your mental wellbeing, a way of making progress and getting positive feedback that you can control. This helps develop long term happiness.

Start Using FP Now

In recent years, each new release of major programming languages has brought them closer to the FP guidelines. Both pure and mostly FP focused languages are on the rise. Competitive startups are choosing FP for their new codebase and existing companies are switching over to help solve large problems.

What’s stopping you to jump in?

Further Reading

The original source for the comparisons is Scott Wlaschin, see his article here.

For a more technical read, have a look at the academic paper Why Functional Programming Matters (John Hughes, University of Glasgow).

. . .

Thanks for finishing the post. If you liked it, follow us on twitter or sign up to to be kept up to date.

If you would like a career in Functional Programming, check out Functional Works.