Immutability

[00:00:00]
>> Kyle: Immutability. Now this is a topic that gets glossed over a lot. So we wanna make sure we pay close attention to this. And in particular, one of the things that I get kind of frustrated about is that when people throw around this word. They could mean one of at least two different things, but they're not very often very clear about what is being discussed.

[00:00:20]
So, let's make sure we understand first why immutability is important, but then, what kind of immutability are we talking about? So, immutability is the idea, obviously, that the word implies that something isn't going to change. But that doesn't fully encompass what we're talking about. It's not just that things don't change, it's that things don't change unexpectedly.

[00:00:44]
There is obviously in our programs a lot of state change, that is the whole point of our programs is for state to change over time and state change being the point. You don't want to stop that from happening. There's really no such thing as like making an immutable program because that program wouldn't have any point.

[00:01:02]
There'd be no reason for that program to exist if nothing could change. So really, this idea of immutability is it's broken in our brains or it's miswired in our brains when we think about it in terms of things that can't change. That's not really the point. Really, the point of immutability is that change that needs to occur needs to be intentional.

[00:01:22]
It shouldn't be accidental, it shouldn't be happening without us being aware, happening at different times, creating race conditions. All those sorts of things. So immutability is this concept of how do we control mutation? How do we control change? And I said there's two different kinds of immutability that we want to pay attention to.

[00:01:42]
So the first of those is assignment immutability. Assignment immutability is the idea that when you assign something to a variable or to a property, that it is no longer allowed to be reassigned to some other value. And this is often a big deal is often made of this.

[00:02:01]
In fact, you'll know we talked earlier in the course about the const keyword. This idea that if I create a variable that can't be reassigned to, that I've somehow prevented myself from having bugs. So let's dig into that. Let's talk about assignment immutability. If I declare basePrice as we are on line one with a var declaration, and then shipping cost with a const declaration.

[00:02:25]
They are both variables. Variable is sort of a weird word here because for a const that can't vary, but it is a placeholder for a value. It is a symbolic representation in memory, so that's why we call it still a variable. Except there's a difference between these two, which is how they're going to handle reassignment.

[00:02:48]
Where they've all declared or even let, if you choose to reassign it to a different value later which is what's happening on line six. No problem of course, everything works fine. But if you try to reassign something that is declared as a const, you get an error saying that's not allowed.

[00:03:05]
It's not allowed for you to change or to reassign. As a matter of fact, we really need to get into the word change. Because the word change implies that we're changing something about the value itself, and we're not really changing the value. basePrice is not being, it's value is not being changed.

[00:03:23]
It's value is being reassigned. We're creating a whole new value with that plus operation, the value 94.99, and we're assigning that new value into basePrice. And the reason why that's important is there are values which can be mutated. A number, for example, can't be mutated. You can't ever change 3.14 into anything other than 3.14.

[00:03:47]
It just is that. Same thing with strings. You can't take the string hello world and modify one of the characters inside of that string. That isn't a thing that you can do. Those values are sort of inherently immutable. They are primitive values that can't really be changed. So we're not changing the value.

[00:04:06]
We're reassigning the value in basePrice. We're creating a new value from an operation, and assigning it into basePrice. And when we try to do the same thing on line ten, we get an error saying, no, that's not allowed for you to reassign. That's what the error means, you can't assign to a consts variable other than at the first time.

[00:04:25]
And by the way, just a little note on const. This is sometimes overlooked. You cannot declare a consts without assigning it a value. So you can't say like const shippingCost, and then later, in that same block of code, give it its first assignment. Because actually, that would mean observing it in two different value states, one where it was undefined and then one where it was defined to a value.

[00:04:48]
And they took great pains to prevent you from observing a variable in this sort of two-state or a const in this two-state situation. Matter of fact, if you've heard, you may have read a blog post about something it's called the temporal dead zone, TDZ. And temporal dead zone is all about preventing us from seeing a const ever be in this weird, in-between, or this gray area state where it was undefined and now it's been defined to a variable.

[00:05:16]
So that we've taken great pains to ensure that you have to assign it that value and then you can't resign it later. Now I've heard many explanations for why we should use a const in our programs. And a matter of fact, some of the most behemoth support for the const keyword comes from the functional programming community that does JavaScript programming.

[00:05:36]
They feel like this is a big boon, it's a big improvement to the language to have a const keyword. I'm not convinced that it really does provide the value that it assumes to provide. And I wanna dig into why I'm not really convinced about that. So if we think about this code, there's another way of avoiding this problem of assignment or reassignment.

[00:05:59]
And this is actually how functional programmers prefer to work. If you think about the argument that a functional programmer makes which says, I don't want my variable to get reassigned accidentally. So I always declare everything with const, that's the typical line, that's the typical statement. But then they don't actually assign many variables anyway.

[00:06:19]
Most of the time, I mean this is called functional programming for a reason, because most of the time, we're not doing assignment statements. Most of the time values are being passed to functions and coming back from other functions. So if you see what's happening here, I can compute the new basePrice or the new shippingCost by simply passing the existing value to a function.

[00:06:41]
Computing it and having that return value come back, and I can or cannot decide to assign that value to some variable. But those are separate questions. The computation of a new value versus the assignment to another variable. They're separate questions. And as a matter of fact, most functional programmers tell you, try to avoid assignment at all costs.

[00:07:01]
You'll see long strings of composition where a function goes to another function, and then it goes here, and here, and here, and here, and here. Because heaven forbid, we assign it to a variable temporarily and then use that variable later. We want to avoid that at all costs.

[00:07:15]
So one of the questions that comes up in my mind when I hear a functional programmer say. No, no, no const, you should absolutely only use const is, do you really even care that much about const? You don't even like to do assignments if you're a functional programmer.

[00:07:29]
So that's one of the reasons why I sort of suspect of, or I'm sort of in doubt of whether or not it's really bringing that much benefit to the table.