JavaScript and Functional Programming

This is a write up of my notes (plus some further research) from Kyle Simpson's excellent class Functional-Light JavaScript (slides here) on 29 of June, 2016.

Object-oriented programming has long been the dominant paradigm in JavaScript. Recently, however, there has been a growing interest in functional programming. Functional programming is a style of programming that emphasises minimising the number of changes to a program’s state (known as side effects). To this end, it encourages the use of immutable data and pure (side effect-free) functions. It also favours a declarative style and encourages the use of well-named functions that allow you to write programs by describing what you want to happen, with the implementation details packaged away out of immediate sight.

Although there are tensions between object-oriented and functional approaches, they are not mutually exclusive. JavaScript has the tools to support both paradigms. Even without using it exclusively as a functional language, there are concepts and best practices from the functional approach that we can use to make our own code cleaner, more readable, and easier to reason about.

Minimise Side Effects

A side effect is a change that is not local to the function that caused it. A function might do something like manipulate the DOM, modify the value of a variable in a higher level scope or write data to a database. The results of these actions are side effects.

// A function with a side effectvarx=10;constmyFunc=function(y){x=x+y;};myFunc(3);console.log(x);// 13myFunc(3);console.log(x);// 16

Side effects are not inherently evil. A program that produced no side effects would not affect the world, and so there would be no point to it (other than perhaps as a theoretical curiousity). They are, however, dangerous and should be avoided wherever they are not strictly necessary.

When a function produces a side effect you have to know more than just its inputs and output to understand what that function does. You need to know about the context and history of the state of the program, which makes the function harder to understand. Side effects can cause bugs by interacting in unpredictable ways, and the functions that produce them are harder to test thanks to their reliance on the context and history of the program’s state.

Minimising side effects is such a fundamental principle of functional programming that most of the following sections can be understood as outlining techniques to avoid them.

Treat Data as Immutable

A mutation is an in-place change to a value. An immutable value is a value that, once created, can never be changed. In JavaScript, simple values like numbers, strings and booleans are immutable. However, data structures like objects and arrays are mutable.

There are, however, several excellent libraries out there that solve this issue, the most well-known of which is Immutable.

For most applications, using a library to enforce immutability is overkill. In most cases you will gain most of the benefits of immutable data simply by treating data as though it were immutable.

Avoiding Mutations: Arrays

Array methods in JavaScript can broadly be divided into mutator methods and non-mutator methods. Mutator methods should be avoided where possible.

For example, concat can be used instead of push. push mutates the original array, whereas concat returns a new array comprised of the array it was called on and the array provided as its argument, leaving the original array intact.

Avoiding Mutations: Objects

Instead of directly editing objects, you can use Object.assign, which copies the properties of source objects into a target object and then returns it. If you always use an empty object as the target object, you can use Object.assign to avoid directly editing objects.

Note on const

const is useful, but it does not make your data immutable. It prevents your variables from being reassigned. These two things should not be conflated.

constx=1;x=2;// not allowedconstmyArray=[1,2,3];myArray=[0,2,3];// not allowedmyArray[0]=0;// allowed!

Write Pure Functions

A pure function is a function that does not change the program’s state and does not produce an observable side effect. The output of a pure function relies solely on its input values. Wherever and whenever a pure function is called, its return value will always be the same when given the same inputs.

Pure functions are an important tool for keeping side effects to a minimum. In addition, their indifference to context make them highly testable and reusable.

myFunc from the section on side effects is an impure function: note how it’s called twice with the same input and gives a different result each time. It could, however, be re-written as a pure function:

Everyone I’ve tried this test on has had more luck with the second example. Example One exemplifies an imperative approach to printing out a list of numbers. Example Two exemplifies a declarative approach. By packaging away the details of how to loop through an array and how to print to the console into the functions forEach and print, respectively, we can express what we want our program to do without needing to go into how to do it. This makes for highly readable code. The last line of Example Two is very close to English.

Adopting this approach involves writing a lot of functions. This process can be made DRY-er by writing functions to generate new functions from existing ones.

There are two features of JavaScript in particular that make this kind of function generation possible. The first is closure. Closure is the ability of functions to access variables from containing scopes, even when those scopes no longer exist. The second is that JavaScript treats functions as values. This makes it possible to write higher-order functions, which are functions that take other functions as arguments and / or return functions as their output.

Combined, these features allow you to write functions that return other functions which “remember” the arguments passed to the function that generated them, and are able to use those arguments elsewhere in the program.

Function Composition

Functions can be combined to form new functions through function composition. Here is an example:

// The function addThenSquare is made by combining the functions add and square.constadd=function(x,y){returnx+y;};constsquare=function(x){returnx*x;};constaddThenSquare=function(x,y){returnsquare(add(x,y));};

You may find yourself repeating this pattern of generating a more complex function from smaller functions. Often it’s more efficient to write a function that does the composition for you:

You could go even further and write a more general composition functions:

// This version of composeTwo can accept any number of arguments for the initial function.constcomposeTwo=function(f,g){returnfunction(...args){returng(f(...args));};};// composeMany can accept any number of functions as well as any number of arguments for the // initial function.constcomposeMany=function(...args){constfuncs=args;returnfunction(...args){funcs.forEach((func)=>{args=[func.apply(this,args)];});returnargs[0];};};

The exact form of your composition function will depend on the level of generality you need and the kind of API you prefer.

Partial Function Application

Partial function application is the process of fixing the value of one or more of a function’s arguments, and then returning the function to be fully invoked later.

In the following example, double, triple, and quadruple are partial applications of multiply.

Currying and partial application are conceptually similar (and you’ll probably never need both), but still distinct. The main difference is that currying will always produce a nested chain of functions that each accept only one argument, whereas partial application can return functions that accept more than one argument. This distinction is clearer when you compare their effects on functions that accept at least three arguments:

Using recursive functions in JavaScript requires some care. Every function call adds a new call frame to the call stack, and that call frame is popped off the call stack when the function returns. Recursive functions call themselves before they return, and so it’s very easy for a recursive function to exceed the limits of the call stack and crash the program.

However, this can be avoided with tail call optimisation.

Tail Call Optimisation

A tail call is a function call that is the last action of a function. Tail call optimisation is when the language compiler recognises tail calls and reuses the same call frame for them. This means that if you write recursive functions with tail calls, the limits of the call stack will never be exceeded by them as it will reuse the same frame over and over.

Here is the recursive function from above rewritten to take advantage of tail call optimisation:

Support for proper tail calls is included in the ES2015 language specification, but is currently unsupported in most environments. You can check whether you can use them here.

Summary

Functional programming contains many ideas that we can use to make our own code simpler and better. Pure functions and immutable data minimise the hazards of side effects. Declarative programming maximises code readability. These are important tools that should be embraced when fighting against complexity.

Corrections

[09-09-2016] Forgot to return the innermost function in partApply, in the section on partial function application. Thank you to Richard Bultitude for spotting the mistake!