I recently read Grokking Simplicity: Taming complex software with Functional Thinking by Eric Normand to formalise my understanding of the foundations of functional programming as I realised I had only ever been introduced to this paradigm anecdotally from colleagues. An extremely practical book that breaks the Functional Programming (FP) stigma that it is a traditionally very theoretical subject. The book avoids the maths and presents digestible, actionable tips and examples laying the foundations. Read on to understand what, why and how it is applied.

What is FP?

"Functional programming provides techniques for organizing side effects so they don't occur just anywhere"

So what are side effects?

Some examples:

• Implicit arguments such as global variables
• If a variable is passed by reference and it is written to inside the function
• Anything that has an external affect such as sending an email or interacting with an external API
• A function is defined as impure if it has any side effects. These functions are also sometimes referred to as actions.

So what are pure functions?

• Opposite of impure functions XD
• Inputs are all explicit arguments. That is they are passed in as actual function arguments. As opposed to an implicit argument such as global variable, which is still an input to a function BUT not passed in as an argument.
• Outputs are all returned values (no implicit outputs)
• No globals (implicit arg)
• Data/pure functions are 'idempotent' (idempotent meaning it doesn't matter how many times it is run/accessed it returns the same result)

Comparison by example:

var someGlobalData = [];

function impureExample(){
someGlobalData.doSomething(); // this global var is both an implicit argument and implicit output
}

function pureExample(explicitArg){
// the function argument here is explicitly an argument
explicit_arg.doSomething()
return true; // explicit output
}

As you can see in the above example, if you were to call the impure function, it can be difficult to tell what side effects will occur, while a pure function is a lot more predictable as you supply the data and can expect a returned value. Hopefully that helps clarify the differences as well as starts showing why Functional programmers tend towards pure functions where possible.

Now, why is this beneficial?

Functional programming works well in distributed systems where Idempotency is important. Idempotency is important when concurrent read/writing and/or actions could be occuring.

Pure functions are also easier to test and more predictable.

Note: this does not mean FP should be applied in all cases (OOP still has its use cases (; ).

Functional programming in practice:

The following is a few key tips to help apply FP:

• Use pure functions where possible (it's impossible to eliminate because they are where actual actions occur but aim to reduce and control where they occur).

• Impure functions create other impure functions
  eg.
  

// this function is also impure because it calls another impure function. The impurity spreads to all the calling functions.
function send_email_wrapper(){
    send_email() // this function is impure because it sends an email ie. it has a 'side-effect' and effects an external system
}

• Keep impure functions small: This can be achieved by pulling all of the data and whatever pure functions you can to be external of the impure function

• seperate data from functions so they evolve independently and are decoupled

• Make pure functions generic

• Use immutable data to avoid side effects. Immutable data is data that can't be changed. So how do you make a system that is not completely static? Make copies, and you will have to change the copies. Read on.

Defensive copying:

This is the idea that by copying the input data inside a function and returning a copy of the data, no side effects should escape from a function.

Summarised as:

• Copy data as it enters the code
• Copy data as it leaves the code

Dealing with async functions:

A general rule for helping to make async functions as 'pure' as possible is to 'return' a callback function (by calling it) rather than returning a value.

Thanks for reading!

This has been a very brief summary highlighting the foundations of Functional Programming as explained in Grokking Simplicity: Taming complex software with Functional Thinking by Eric Normand. A fantastic read for anyone looking for a practical read on functional programming principles.

Thanks again for reading and feel to leave any thoughts in the comments!

Follow me for more book reviews and quick tips I pick up along the way as I continue my book-per-week reading journey.

For my full reading list: https://github.com/SeanOverton/books-i-have-read/blob/main/books.yml