Immutability

The single most important aspect of FP is immutability.¹ Generally speaking, this means a lack of change. Something is considered immutable, if we cannot modify it in some way. In functional programming this means a few things. Once a variable is set, its value cannot be changed. If x = 3 at the beginning of a program, it has that value for the remainder of the program. Does that mean that if a program is written in a functional style, and a person’s age changes, this change cannot be modeled? Of course not. That would be a disaster for functional programming. There are techniques like copying that allow us to efficiently, manipulate our code, without ever mutating state. Consider the following simple for loop in Java that prints the numbers 0 to 99.

Java

for (int i = 0; i < 100; i++) {
    System.out.println( i );
}

This type of code occurs all the time. You might wonder how we could possibly express this in an immutable way. It seems that the essence of this code is the changing of the value of the variable i. A common approach in FP is to use recursive functions. A recursive function is a function that calls itself. In the case of the above code, you can put the code in a function and then call the function on the next value of i, in each iteration. It might look something like:

Java

void f(int i) {
    if (i > 99) {
        return;
    }
    else {
        System.out.println( i)
        return f(i+1)
    }
}

f(0)

Now this code is a little longer but it does not mutate any state. If you know a little about FP, you might know that the return type of void is a sure giveaway that there will be side effects.² A side effect is anything that affects the program outside of the function. Things like writing to a file, throwing an exception or modifying a global variable. The above example is just meant to show one way of avoiding the mutation of state. You have probably been mutating state your whole programming career and it likely seems indispensible. But remember two things

The good news is that with practice, the FP way will feel just as natural.

Let us consider another technique for avoiding the mutation of state. Imagine you have an object, which has a property, or field and it changes. Remember, I never made the claim that this never happens. That would be absurd. The point is to model this situation without mutating a variable in the code. Let us consider a Java example first.

Java

public class Person {
    private final String name;
    private final int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }


    public static void main(String[] args)  {
        Person person = new Person("Carl", 32);
        //A year passes
        Person changedPerson = new Person("Carl", 33);  
        System.out.println(changedPerson);
    }
}

Instead of modifying the value of age in the Person object, we create a new object and initialize the new age value in the constructor. Let us now look at an example in Python.

Python

class Person:
    def __init__(self,name,age):
        self.name = name
        self.age = age

    def main():
        person = Person("John",22)
	#One year later
	changedPerson = Person("John",23)

One year passes and we need the person object to reflect this. But we can’t modify the value age. So we create another immutable object with the age variable initialized to 23

Let us now look at an example in Scala.

Scala

case class Person(name: String, age: Int) 
val person = Person("Katherine", 25)      
val changedPerson = person.copy(age=26)                       

Declare a case class

Create an instance of the class

This line makes a new instance of Person and initializes age to 26. No state has been mutated.

You may recall that I believe immutability to be the most important aspect of FP. Lots of mutable state in a program is a source of many bugs. It’s simply not easy to keep track of all the changing values. Above, we have seen some examples of how to get around the apparent need to mutate state. It takes some getting used to but with a little practice, using these techniques may even start to seem natural.

Referential Transparency

You have seen some examples of immutability. Now we will look another crucial piece of what makes up FP, Referential Transparency. We say an expression is referentially transparent if we can replace it with its value anywhere in the code. You might think, upon first hearing about this, that you can always do this. Let us consider a simple example of a non referentially transparent function.

Java

today()

If I call this function, and get, say May 29th, 2021, and I replace its body with this value, and then call it tomorrow, I will get the wrong answer. It might seem impossible to express this function as a referentially transparent function but we will see how to approach this in a functional way later in the book.

Here are a few more examples of non referential transparency:

• A function that returns a random number. Obviously you can’t replace the body of the function with a value you get when you call it once.

• A function that throws and exception. Exceptions are generally avoided in FP. I will come back to that later.

It probably seems that if we throw out all non referentially transparent functions (and that is what we will aim for), that we will lose some valuable capabilities. It seems there will be many useful things we need to express but will not be able to. Rest assured, there are functional ways of expressing these things and once you get use to them, they may even seem more uniform and simpler.

A related concept that you will see in writings about functional programming is purity. I am afraid to say there is some confusion in the literature about the relationship between purity and referential transparency and not everybody agrees on the meanings of these terms. Generally, a function is said to be pure if it has no side effects and for a given input, always returns the same output. This basically means that if you put in the same input,you get out the same output. If the input is x and the output is y, no matter how many times you call the function with x as the input parameter, the function will return y. A side effect is anything that happens outside of the context of the function. Writing to a file and throwing an exception are two examples of side effects. Forget for the moment that we need to write to files, (though arguably we don’t need to throw exceptions) and think how nice it would be if everytime we call a function with the same input parameters, we get the same output and nothing, outside of the function is changed. That is something we enjoy in functional programming. Because different people have different views on this, and because the differences between referential transparency and purity are subtle, I will treat the two terms as synonymous.

Now, I said you don’t have to be a mathematician to write functional programs and you don’t. But functional programming does come from mathematics. A field called lambda calculus, to be precise. Much of it also comes from a field called category theory. Category theory has much to do with functions. And in mathematics, functions are what we pure. When a programmer looks at an expression like x = x + 1, she says ah, increment the variable. When a mathematician looks at x = x + 1, she says No, its not.³

Now what would an impure function look like?

Scala

object Main extends App {
 def impureFunction(x: Int): Int = {
 import scala.util.Random
 return Random.nextInt(100) + x
 }
 println(impureFunction(5))
 println(impureFunction(8))
}

The two function calls will very likely return different output values for the same input value. This function is not pure. We have said mathematical functions are pure. Well, programming has gained quite alot from this mathematical approach. Functional programs are clean and pure and elegant. The functional style of programming may take a little bit of getting use to at first,but as we gradually move through the basic ideas of functional programming in this book, you will little by little start thinking like a functional programmer. Your functions will be pure and your code will be clean. The biggest benefit, however, of writing functional programs is that you will have a much stronger expectation that your programs will be correct.

Let me make an important point here. We can’t ultimately just define what FP is in a negative way. We can’t say its the same as ordinary programming except that we leave out this and this and that and the other thing. The hard part, the part accomplished by the many creators of FP is how to express everything we need, in a functional way.

Higher Order Functions

Functional Programming is all about functions. What we want, in a functional programming language, is the ability to treat functions as first class citizens. This means we should be able to pass them as function parameters and return them from functions as return values. Let’s discuss why higher order functions are an important part of functional programming. One key goal in functional programming is to get to the heart of the matter. This means we need to be able to express concepts concisely in our language. If we want to square every integer in a list, for example, we shouldn’t have to loop through the list and modify each number by squaring it. We should be able simply to directly apply a square function to every element of the list simultaneously, as it were. The map function, in many languages, allows us to do this. It allows us to work at a higher level of abstraction. That higher level corresponds to a higher order function. We will see this as a major theme as we proceed.

Example 1 (an imperative approach)

Python

def square(nums):
    squared = []
    for i in nums:
    	squared.append(i*i)
    return squared

Example 2 (a functional approach)

Python

def square(nums):
    return map(lambda n: n*n, nums)

As you saw in chapter 2, lambda is a way of creating an anonymous function; that is, creating a function with out a name. The map funtion that acts on members of a list, and all at once, applies it to all the elements of the list.

Lazy Evaluation

Another component of functional programming is lazy evaluation. This simply means an expression is not evaluated until it is needed. This is not, strictly speaking, necessary for a language to be functional but often languages which are, by nature, more functional, tend to be lazy. Haskell, for example, is lazy by default. Most popular languages are not lazy though, and they use, what is called, eager evaluation. This means an expression is evaluated the first (and every) time it is encountered. As you’ll see in the example below, there are two benefits of lazy evaluation:

• It allows you to define control flow structures in your code directly as opposed to having to be operators built into the language.

• It can speed up performance.

Imagine you want to define your own if statement. Let’s call the function myIf. You might want to add a logging line to every if statement, for example. If you try the following, you will encounter a problem.

Scala

def myIf(condition: Boolean, thenAction: Unit, elseAction: Unit): Unit = if (condition)
      thenAction
    else elseAction

Can you see the problem with this definition? With eager evaluation, which most common languages have, when the function is called, the first thing that happens is that all of the parameters are evaluated. So in the case of myIf, both the thenAction and the elseAction will be evaluated when you only want one of them to be evaluated, depending on the condition variable. However, with lazy evaluation, this would work. In this and related cases, it would allow you to write your own control statements. Another benefit is performance improvement in certain situations. Since the lazy code is only evaluated when it is needed, it is often the case that it is actually evaluated less than it would be in the eager evaluation case. This can speed up the program.

In Scala we can use call by name parameters. In the code below, thenAction and elseAction are only evaluated when they are needed. That is, they are evaluated lazily. The following will work as expected.

Scala

def myIf(condition: Boolean, thenAction: => Unit, elseAction: => Unit): Unit = if (condition)
      thenAction
    else elseAction
}

Thinking likek a functional programmer

In this book, we will focus on how to think like a functional programmer. This presupposes, of course, functional programmers think a certain way. While there are a wide range of approaches to functional programming, there are basic ideas functional programmers use and and basic ways of thinking. Functional programmers don’t mutate state, for example. That is once a variable has been set, it is never changed. Also, functional programmers tend to use lots of higer order functions. These are functions that take other functions as parameters and/or return a function as a return value. But to know how a functional programer really thinks involves knowing a set of idioms, or patterns that promote functional code. It’s all well and good for me to tell you not to mutate your variables, but unless you know how, specifically to do this, implementing immutability may not make any sense. In other words, patterns are an important part of functional programming.

Now you may have heard that functional programmers don’t really care as much about patterns as object oriented programmers do. This is largely mistaken. What is true is that the term pattern, in the context of FP refers to something different than the Gang of Four patterns. The Gang of Four patterns were developed in the context of object oriented programming. Patterns like the Prototype, Proxy and Flyweight patterns. These can largely be implemented in a functional style and are useful in the design of programs. But there is nothing particulary functional about these type of patterns. One might say they are functional - neutral. There is another type of pattern that is quintessentially functional and these are ideas that come from category theory. We will address this in some detail in chapter 3.

The Benefits of Functional Programming

The benefits of functional programming are by now clear. It aids us in our quest for bug-free code. Or as close to bug-free code as is possible. And how does it do this? By rewiring our brains, as it were, so that we no longer see the world as a mass of objects each with its own changing state and processes that transform that state in such a whirlwind of complexity that we can hardly wrap our minds around it. There is no doubting it now. State is the culprit. When things change, we need to keep track of them. And that is the problem. A multitude of variables and objects each with its own state, and each with its own set of transformations modifying it. Many a night has been spent by a tired programmer searching for a bug created by a change in state somewhere in the program. There is only so much complexity the human mind can bring under its control. Only so much complexity we can take, before we start writing code that isn’t quite correct. But ’wait’, you say. ’The world is made up of objects. And those objects have state, and that state changes over time! So we are right to model the world this way. That’s exactly how the world is!’ And to that, I respond, maybe, maybe not. There is another way of looking at the world, however, which might make thinking functionally easier. We will address that at a later time.⁴

For now,the important thing is to realize that writing bugfree software is not something we really know how to do. I knew a Computer Science professor who once started off his introduction to programming class with the sentence The human race does not yet know how to program. A bit dramatic, perhaps, but true. Projects typically come in above budget and take much longer than predicted. The reason is complexity. Programming is the art and science and engineering of managing complexity. Functional programming brings with it tools we can use in an attempt to restrain and control this complexity. Tools like immutability, referential transparency and higher order functions, to name a few. Master these tools and your code will be better, and more bug-free.