Why Functional Programming Matters

At Pesto, we were recently taught two things: Programming Deliberately and Functional Programming. Programming Deliberately means knowing every bit of code that we are going to write.

We have to do some homework, to help us clearly understand the concept of Programming Deliberately. We need to read an academic research paper from PapersWeLove.org and then write a Medium post about it.

The paper I read is Why Functional Programming Matters by John Hughes and here’s what I learned from it.

Functional Programming is so called because the program consists entirely of functions. Even the main program is a function, which receives input as an argument and generates output as its result.

The key concept of Functional Programming is Modularity. The program functions are always defined in terms of other functions which are further defined in terms of smaller functions.

Functional Programs contains no assignment statements and contains no side-effects. The functions have to be Pure functions i.e. will produce same output every time when given the same set of inputs.

Hughes summed up FP perfectly:

The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these “advantages” are totally unconvincing.

Advantages of Functional Programming

• Small modules can be coded quickly and easily.
• General purpose modules can be reusable, which leads to faster development of next programs.
• The modules of a program can be tested independently, helping to reduce the time spent debugging.
• Functional programs are referentially transparent i.e. if a variable is assigned a certain value in a program, then this value cannot be changed again.

The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together.

The two glues are:

1. Higher-order Functions
2. Lazy Evaluation

A function is called Higher-order function if it takes a function as an argument or returns a function as a result. Simple functions can be glued together to form a complex one. Here’s an example:

add x y = x + y
sum = reduce add 0

Here add is a function which takes two variables x and y as arguments and returns their sum. And reduce is the higher-order function which has add function as its argument and ‘0’ is the passed as the first argument to add function.

//Brackets are added just to make things clear

sum = reduce(add(0)) 
sum = reduce(add 0)

//Printing sum(5) will print the sum of 5 and 0 i.e. 5
//This is how it happens

\> sum(5) = reduce(add 0) 5
\> sum(5) = reduce(add 0 5)
\> sum(5) = 5

Lazy Evaluation is also referred to as call-by-need evaluation strategy which delays the evaluation of an expression until it is needed and is also avoids repeated evaluation.

Lazy evaluation can be also be achieved in imperative languages but will make things rather difficult. This can only be of use when our programs have high modularity.

Because lazy evaluation’s power depends on the programmer giving up any direct control over the order in which the parts of a program are executed, it would make programming with side effects rather difficult, because predicting in what order — or even whether — they might take place would require knowing a lot about the context in which they are embedded. Such global interdependence would defeat the very modularity that — in functional languages — lazy evaluation is designed to enhance.

Modularity is the key of successful programming and to assist modular programming, language must provide good glue.

If you want to dig a little deeper into the details, then feel free to read the whole paper yourself or check out other interesting papers on PapersWeLove.org.