If we avoid mutable state

Simpler programs

No side-effects means simpler programs. This definition of ‘simple’ means ‘easier to reason about’. Because we don’t need to worry about parallel access, or about ‘what has happened before’ we can just reason that ‘given an X we get a Y’, and this is true no matter how many exceptions have happened, or simulataneous threads are hitting the method

Fewer bugs

By avoiding mutable state we avoid whole categories of bugs: locking issues (see below), the issues of an object getting into a funny state because of an exception, and so on.

Easier to test

The simplest possible thing to test is a pure function with no side effects (and mutating state is a side effect)

Trivially parallelisable

Shared mutable state is very difficult to work with in a parallel system. The classical approach is to use locks and keys, but this leads to live locks, dead locks, and the need to have a global lock order. Another approach is to do everything in a framework (like J2EE) which imposes a heavy runtime burden as well as a heavy programmer burden (like no reentrant code).

With no immutable state we don’t care about locks and keys and can trivially parallelise everything. The efficiency of that parallelisation is a different matter

Advanced uses

Typically avoiding mutable state results in systems that trivially implement transactions and undo/redo

Don’t destroy your code for the sake of dogma

It takes time, education and experience to learn how to work with immutable state. If you don’t have that skill and experience you can request training. The critical thing to avoid is shared mutable state. Most code can be trivially converted to using immutable state

Links:

Really interesting ‘core idea’ things on the philosophy of why this is important