Trying to understand the benefits of immutability in imperative programming

Question

I'm learning about immutability (specifically in C#) and I can't understand the examples out there stating that making an object immutable brings real benefits (besides a shared object in a multi threaded environment, which the benefits are pretty clear).

The most talked example in my readings is DTOs. It's said that DTOs are a great example of a use case where the object should be immutable, but the reasons of it are not explained (or at least I couldn't understand). Okay, DTOs shouldn't change, but what are the benefits from enforcing that those types are immutable? Is it just that by making a DTO immutable, we are being more descriptive about the role of the object in the system? Does it goes beyond that?

Answer 1

Like most "functional" concepts, this one has been over-hyped.

At some point, in almost all programs that are useful in a business context, something must mutate. Doing so in a correct and disciplined way is part of the art of programming.

In terms of benefits, you identify the obvious case of concurrent access to a shared object. What's not clear is why the shared object is being mutated at all, if it isn't necessary to do so. Most programmers instruct mutations on purpose because the mutations perform a necessary function, not by a slip of the keyboard.

If it is necessary to mutate, then making everything immutable is no solution to the problem. It just pushes the problem around to another area of the program, where eventually something (perhaps even, a lot of things) must in fact mutate.

And whatever was to be gained by immutability, will perhaps be lost again by unintentionally holding expired data, which is the mirror image of unintentionally updating shared data.

If there is any grain of truth about immutability, it is probably this. Mutations to "master data" (and exactly what that is may differ from program to program, but it is typically the part which is stored indefinitely) should be planned out, retaining all intermediary values until the completion of the operation (i.e. don't reuse variables and objects for multiple steps of a calculation), and then the final changes to the master data should be applied "at once" (i.e. in a relatively localised area of the program).

This contrasts to "worker-bee" type approaches where there are many subroutines (perhaps on multiple threads) applying many incremental changes all over the master data, and which have often already thrown away intermediate values for one change before they have have even decided/calculated what the next change will be.

The widespread use of immutable objects, where any necessary mutations of shared data must always be pushed to a relatively high level in the program/call stack, make this worker bee approach prohibitively difficult from the outset. Other things can still go wrong, but it helps that problem at least.

Answer 2

Consider testing. When you test a function that mutates some internal state, you have two headline options.

One is to assert a specific mutation. This might be accomplished through a mock expectation for some upstream stateful object, or through reading the value of private instance variables. Either way, the test becomes tightly coupled to the implementation. It will be very difficult to refactor the method without upending its unit tests, which defeats much of the purpose of having them.

Another is to instead verify that the mutation has the desired effect on future behavior. For example, after I place an element into a collection, I should be able to read it back. This option better respects the privacy of the collection's implementation. It gives the class under test more latitude to choose its internal representations, as long as it exhibits the behaviors I check for. The problem is it could do literally anything to the behaviors I don't check. For example maybe my linked-list insertion is buggy, and inserting an element will cause the list to lose a different element.

Pure functions don't have this problem. I can assert that when I call a function with a certain input, it returns a certain output. And that's it. That's the only thing it does. As long as I assert the whole identity of the value returned, there can be no surprises about other consequences of having run the function.

Answer 3

The biggest advantage of making objects immutable is that it makes it easier to understand and reason about the code.

Even with single-threaded code, you don't have to consider the possibility that a function you call might change the value of the object.

For a 2000 line program, this is not really critical, because the program is small enough to be able to follow all the modification it makes to objects. But as programs grow larger, that size increase makes it harder to understand what the code is exactly doing if if that is the correct thing. Then (compiler diagnosed) immutability can help you free up mind capacity to think about other things that need to be correct.

Answer 4

Immutability makes memory management a lot easier. Rather than messing with an existing object to change it and synchronizing shared access to it, a new instance is created and the old one is discarded. This can make things less efficient from a performance point of view but it also makes things easier and more robust.

Creation logic is needed anyway so it might as well be reused for assignment logic. If a change requires reallocation of an object, you might as well recreate it with any change, always, and be done with it,

Answer 5

In my experience immutability usually had 2 major benefits.

1) When used consistently throughout the whole program, it gives extra information about the code, for the next developer working on it.

If a local variable is mutable (even if it was not supposed to be), the next time someone modifies that piece of code, they might not spend the time to evaluate if that was meant to be mutable or not. But if you declare it immutable (for example writing out const or final), that will make the next developer working on that code assume, that you meant it to be immutable, making it mutable and changing its value might break something somewhere.

2) In compiler construction, there is a technique called "constant folding". In simple terms this roughly means, that if the compiler understands that some operation is done on immutable parameters ... it can decide to calculate the resulting value in compilation time and generate that into the executable instead of the operation itself. (for example instead of generating code for x = 1+1, the compiler could just generate code for x= 2 ... this is faster to perform during execution)

Building on this you can write code, that is expressive in its source code form, but does not incur any actual operation during execution.

That said, compilers also have to balance how much effort they put into this kind of optimization: if they don't do constant folding aggressive enough they can leave performance improvements on the table, but the more time compilers spend on finding more situations to optimize the longer the compilation takes.

Immutability can be like offering a helping hand to the compiler. If you have a long and complex function, identifying if a local variable could be immutable might be too costly for the compiler to perform. But if you declare that variable immutable the compiler can save all that hard work and find some places where constant folding can be used.