Functional Programmers will talk about immutable values. What do they mean? How can you write software where none of the values change?
►► Audio, Video, and Transcript available: https://lispcast.com/what-is-immutabi...
►► Subscribe on iTunes: https://itunes.apple.com/us/podcast/t...
Transcript
What do we mean when #functionalprogrammers talk about immutability? Do things really have to never change?
Hi, my name is Eric Normand. These are my thoughts on #functionalprogramming. Immutability is one of those things that comes up a lot when people are talking about functional programming.
I want to talk about some of the more practical aspects of it, not just the theoretical. The theoretical says that an immutable value cannot be changed. Now, in practice, there are several ways that you can enforce that.
Sometimes you don't have immutability in your language so you have to do something else. It's really just how you interpret that cannot. One thing is, the language could enforce it or the particular object, the data itself, might not have any methods on it that allow it to be mutated.
That is one way of enforcing this discipline, this rule, that things shouldn't be mutated, they can't be mutated. Another way is you could just have a, let's call it, a developer policy that says, "We don't mutate."
Maybe the object is mutable. You could but you don't. You just apply the rule, but you have no help from the language, your compiler, or anything. That's the practice of it.
If you're in #JavaScript and you have some mutable thing like a JavaScript object or you have a JavaScript array, those are mutable. You could practice immutability by, in practice, never changing them even though you could. Given that you could change them, there are...
You need to make modified versions of these things. Even if you aren't changing the thing, you want to be able to add a new element to your object or to your array. How do you do this?
There's actually two and a half disciplines for doing this. The first one is called copy-on-write. This means whenever you need to make a modification to an object, you don't know who else has a pointer to that object so you don't want to change that because then you're breaking your rule of immutability. You make a copy and then change the copy.
You're changing it. You're using mutation, but no one has a reference to it yet. No one has seen it but you. Then, once you give it out now, boom, the immutability rule is now enforced and no one else can change it. You're not going to change it and you're saying no one else can change it.
The rule has to be applied unilaterally. Once you give away a pointer to it, you cannot change it. If you get something that you didn't create yourself, meaning you know exactly the code path that it went through to get to you, you can't change it either because someone else might already have it.
Those are the two rules. If you get something, you can't change it. If you need to make a change, you have to make a copy and then change that copy that you control. That's called copy-on-write.
There's another one called copy-on-read. This one is, if you get something from someone and you're not sure of this library, this API that you're using, believes the same things you do about immutability.
If it's even implemented correctly, if they enforce the rule properly, so you don't believe that this thing, this system, is immutable. What do you do? You make your own copy of the thing.
That means that the library can modify the one that it gave you all it wants. What's important is that the one that you keep is under your control and you're only going to pass it to things that you believe will be immutable.
Let's talk about the rules of this. If you get something from an untrusted source and you don't trust that it enforces immutability, you make a copy and you throw away the old one. You throw away the one they gave you. You just immediately make a copy and that's the one you keep.
Then, if you're going to give your ostensibly immutable thing to something else, you don't trust that it's going to maintain your discipline of immutability, you have to make a copy before and give them the copy.