(true? "data is immutable")


#1

This question may be a bit different…

I was talking to a friend of mine who spends most of his day building desktop applications / services for windows. He was interested in what I’ve been studying and started watching the talk “Clojure, Made Simple”.

He took issue with some things that I found to be fundamental pillars / tenants. “Data is immutable” was one point of contention. He argued that since storing data alters the physical state of memory on the machine it is therefore mutable. I remarked that data you receive is just data, if “data changes” it’s actually new data or a new fact, an old value is still valid data or a valid fact at that point in time.

I think the disagreement is due to a fixation on the state of the machine always changing vs talking about the layer of abstraction I’m working in when I say "a piece of data is immutable, i can run a pure function against it and it returns another immutable data-structure.

What do you guys/gals/robots think?


#2

This is a great question. You don’t know how many times I’ve had this conversation.

In fact, I had the conversation enough times that I wrote this article about it:

But the World is Mutable

The short answer is: the world is mutable and paper is mutable, yet reliable systems are built by treating paper as write-once (or append only). Immutable computer systems do the same. You write the data once to RAM and you don’t touch it again. If you need to change it, you do so in unused RAM.

And I think you’re right: he’s thinking at a low level, like his job is to control the state of the computer, not to model the domain.


#3

Yes, I’ve encountered this argument many times. To some extent, I find it often comes from people who are frequently too pedantic about definitions. It often reminds me of Sheldon from the Big Bang Theory.

I first came across the concept of immutability when I was first introduced to functional programming many years ago while at Uni. The topic would often come up in discussions regarding side effects and that in order to interact with the ‘real world’ mutability and side effects could not be avoided.

I think that what is often missing when people get hung up on immutability is a failure to acknowledge that we are not stating that the world is immutable. What immutability is about is a model for reasoning about the world which helps to reduce complexity. The other argument against immutability use to relate to inefficiencies. It would be argued that modifying data was more efficient than copying it or having many copies of data which only vary slightly. While there is some truth to the efficiency argument, the reality is that advances in algorithms and processing power make the efficiency aspects less of a concern than they were previously.

When I’ve discussed immutability with developers who have come from a more traditional procedural language perspective, I tend to focus on the benfits of immutability for reducing complexity and simplifying testing or proving correctness. In this age of multi-core processors, I also find examples involving concurrency/parallelism to be very useful. Emphasising that we are talking about how to model a problem and that a model doesn’t have to faithfully reproduce the real world, only model it in a reliable and consistent manner also helps.


#4

Just to add a little more to the debate:

In this talk, Greg Young says (paraphrasing): “Any mature domain model doesn’t modify data.” He uses, by coincidence, the same two domains I used in my article, namely accounting and medical records.

This adds a little because it’s basically saying models will get there if they stick around long enough.


#5

Thanks I’m a ways into the talk and it’s very interesting so far. “DDD is great, but expensive, don’t use it for everything…” leads me to believe this guy is a careful critical thinker. More thoughts potentially later.