John Carmack on mutable variables

After a 2 year Clojure stint I find it very hard to explain the clarity that comes with immutability for programmers used to trigger effects with a mutation.

I think it may be one of those things you have to see in order to understand.

I guess I'm not that good a programmer, because I don't really understand why variables that can't be varied are useful, or why you'd use that.

How do you write code that actually works?

It forces you to consider when, where and why a change occurs and can help reason later about changes. Thread safety is a big plus.

Okay, so for example I might set something like "this bunch of parameters" immutable, but "this 16kB or so of floats" are just ordinary variables which change all the time?

Or then would the block of floats be "immutable but not from this bit"? So the code that processes a block of samples can write to it, the code that fills the sample buffer can write to it, but nothing else should?

Sounds like you have a data structure like `Array<Float>`. The immutable approach has methods on Array like:

   Array<Float> append(Float value);
   Array<Float> replace(int index, Float value);

The methods don't mutate the array, they return a new array with the change.

The trick is: How do you make this fast without copying a whole array?

Clojure includes a variety of collection classes that "magically" make these operations fast, for a variety of data types (lists, sets, maps, queues, etc). Also on the JVM there's Vavr; if you dig around you might find equivalents for other platforms.

No it won't be quite as fast as mutating a raw buffer, but it's usually plenty fast enough and you can always special-case performance sensitive spots.

Even if you never write a line of production Clojure, it's worth experimenting with just to get into the mindset. I don't use it, but I apply the principles I learned from Clojure in all the other languages I do use.

> The methods don't mutate the array, they return a new array with the change.

But then I need to update a bunch of stuff to point to the new array, and I've still got the old incorrect array hanging around taking up space.

This just sounds like a great way to introduce bugs.

It ends up being quite the opposite - many, many bugs come from unexpected side effects of mutation. You pass that array to a function and it turns out 10 layers deeper in the call stack, in code written by somebody else, some function decided to mutate the array.

Immutability gives you solid contracts. A function takes X as input and returns Y as output. This is predictable, testable, and thread safe by default.

If you have a bunch of stuff pointing at an object and all that stuff needs to change when the inner object changes, then you "raise up" the immutability to a higher level.

    Universe nextStateOfTheUniverse = oldUniverse.modifyItSomehow();

If you keep going with this philosophy you end up with something roughly like "software transactional memory" where the state of the world changes at each step, and you can go back and look at old states of the world if you want.

Old states don't hang around if you don't keep references to them. They get garbage collected.

Okay, so this sounds like it's a method of programming that is entirely incompatible with anything I work on.

What sort of thing would it be useful for?

The kind of things I do tend to have maybe several hundred thousand floating point values that exist for maybe a couple of hundred thousandths of a second, get processed, get dealt with, and then are immediately overwritten with the next batch.

I can't think of any reason why I'd ever need to know what they were a few iterations back. That's gone, maybe as much as a ten-thousandth of a second ago, which may as well be last year.