The Profligacy of Immutability

Introduction

There are reasons that we stopped chiselling information into stone tablets, so let’s just hope those same lessons can be re-learned before we head too far down that road again with immutable data objects.

The Analogy

Things constantly change - ideas, facts, numbers, etc. And when they did, we couldn’t just rub out and replace a few words on our stone tablet. We had to go out and find another stone, cut it to the same size, chisel in all of the exact same information again - except for those few words that needed changing, drag it back to the athenaeum and replace the old tablet on the shelf with the new one. Then we had to drag the old tablet out back, throw it on an enormous pile of other recently replaced tablets, and wait for the garbage collection carts to call by whenever they could. When they did show up, usually at a most inconvenient time, we all had to stop whatever we were doing and go out back to help throw old tablet shards onto the carts to be taken away.

Hopefully you can see where I’m going with this, because I’m only just getting started…

So, one day Emperor Hideous decided on a name change, and then really didn’t like the old one. Unfortunately, the new name was quite a bit longer, which meant that every tablet that mentioned his old name had to be redone. So the athenaeum had to hire a whole heap of local people to go out looking for new stones, and a whole heap of scribes to make copies of the old tablets but with the new name. This process started to create an even more enormous pile of old discarded tablets. To get rid of them, the garbage collection carts just kept coming almost constantly, one after the other, until the athenaeum workers were spending pretty well all of their time out back helping throw old tablet shards onto carts.

This process lasted for several months, during which time the Emperor began to grow a bit nostalgic about his old name.

Immutability and Dynamic Animation

I can understand that immutable data objects are more thread-safe and offer some functional programming benefits in large complex projects where debugging may be tedious. However, we now live in a digital world of fluid and dynamic user experience, where 2D and 3D data is expected to smoothly transition between states with stutter-free animation running at 60 frames per second. Using immutable data objects in this context voraciously gobbles up new memory and leaves behind piles of discarded trash that someone else has to clean up, making smooth continuous animation a process of pot-luck that is dependant on each system’s garbage collection policy and capacity.

Yes, I know the stone tablet analogy is ridiculous, over-the-top and self-serving - but philosophically, is it really that wide of the mark?

I have no problems with functional programming, or even striving to use functional programming techniques wherever appropriate as there is no doubt that they do solve particular classes of problems. However, imposing immutability on objects in a library intended to be used by others, especially when it is not intrinsically important to that library’s own operation, can end up creating whole new classes of even more difficult problems. With many of these new problems only discoverable after all the implementation work required to get it going.

As a library developer, how can you be so absolutely certain that your work will never be used in highly dynamic situations that you intentionally disallow the reuse of object instances? Surely this is the programming equivalent of extreme built-in obsolescence, not caring about how many resources get used up or how much garbage gets left behind.

As someone who often tries to use libraries in highly dynamic situations, all I ask is that you take just a little time to consider whether your objects really do need to be immutable. Even if the answer is absolutely yes, then surely it is still possible to make some accommodation for those of us who do want to recycle and reuse our data objects.