Why do immutable objects enable functional programming?

Question

I'm trying to learn scala and I'm unable to grasp this concept. Why does making an object immutable help prevent side-effects in functions. Can anyone explain like I'm five?

Answer 1

Interesting question, a bit difficult to answer.

Functional programming is very much about using mathematics to reason about programs. To do so, one needs a formalism that describe the programs and how one can make proofs about properties they might have.

There are many models of computation that provide such formalisms, such as lambda calculus and turing machines. And there's a certain degree of equivalency between them (see this question, for a discussion).

In a very real sense, programs with mutability and some other side effects have a direct mapping to functional program. Consider this example:

a = 0 b = 1 a = a + b 

Here are two ways of mapping it to functional program. First one, a and b are part of a "state", and each line is a function from a state into a new state:

state1 = (a = 0, b = ?) state2 = (a = state1.a, b = 1) state3 = (a = state2.a + state2.b, b = state2.b) 

Here's another, where each variable is associated with a time:

(a, t0) = 0 (b, t1) = 1 (a, t2) = (a, t0) + (b, t1) 

So, given the above, why not use mutability?

Well, here's the interesting thing about math: the less powerful the formalism is, the easier it is to make proofs with it. Or, to put it in other words, it's too hard to reason about programs that have mutability.

As a consequence, there's very little advance regarding concepts in programming with mutability. The famous Design Patterns were not arrived at through study, nor do they have any mathematical backing. Instead, they are the result of years and years of trial and error, and some of them have since proved to be misguided. Who knows about the other dozens "design patterns" seen everywhere?

Meanwhile, Haskell programmers came up with Functors, Monads, Co-monads, Zippers, Applicatives, Lenses... dozens of concepts with mathematical backing and, most importantly, actual patterns of how code is composed to make up programs. Things you can use to reason about your program, increase reusability and improve correctness. Take a look at the Typeclassopedia for examples.

It's no wonder people not familiar with functional programming get a bit scared with this stuff... by comparison, the rest of the programming world is still working with a few decades-old concepts. The very idea of new concepts is alien.

Unfortunately, all these patterns, all these concepts, only apply with the code they are working with does not contain mutability (or other side effects). If it does, then their properties cease to be valid, and you can't rely on them. You are back to guessing, testing and debugging.