Rethinking const Immutability

[00:00:00]
>> Kyle Simpson: Here's another reason why I'm kind of concerned about the proliferation of const within our language. There is a lot of baggage that comes with the const keyword. Certainly this is not a new invention for the JavaScript language. Const was added to languages decades ago. And if you look even on a site like Stack Overflow and do a search for questions about a const keyword, you can find thousands and thousands of questions and problems that people have had with this keyword, in basically every language that it's ever been added to.

[00:00:35]
And I think one of the root reasons, if I'm trying to approach that question as an educator, as somebody that tries to understand what problems people who are learning things have. And what they need to do to get over those problems. When I look at it from that lens, I think the real problem comes down to the English language being difficult to parse alongside of programming language.

[00:00:57]
When we say the word constant, a lot of us mean, something that doesn't change. When we say that in sort of everyday language, if we said the temperature has been constant today, it hasn't changed today, that's what we mean. So we're implying something that doesn't change, and that's to this gray area, what thing is it that's not changing with a constant?

[00:01:19]
So if I point const at a value, if I point a const declaration at a value, that itself cannot change like 6.5, that's sort of a moot point. [LAUGH] The value can't change anyway, so it doesn't matter. But if I point it at a thing that can change, for example, an array, now all of a sudden, we see that there is a nuance difference that is really important.

[00:01:40]
It's nuanced, but actually, it should be the whole thing. Because the question is whether or not we care about reassigning a variable, or whether we care about a value that could be mutated, having been changed. For example, adding or removing an element from an array, or reassigning one of the properties of an object.

[00:01:58]
Those are mutations to a value that are possible with certain value types, like arrays and objects, which basically aren't possible with a number or a string. So when we use a const with something primitive, that isn't already changeable, it's not such a big deal. The nuance doesn't present itself.

[00:02:16]
But when you start, for example, assigning functions to const, like we're doing here on line 3, functions are actually objects. And they can have properties on them. That isn't typically done that much, but you can use a function as an object. And of course, that means the value can be mutated.

[00:02:33]
And even worse, when you use const with real objects or with real arrays, you create this confusion, I think, in people, where they think in their mind initially, that is a value that isn't gonna change. When actually, what the const keyword is saying is it's an assignment that isn't gonna change.

[00:02:49]
So if I create an array and then assign it with a const declaration, and then later that value changes, the most likely outcome is that the reader is gonna be confused. Certainly you can learn to get along with the const keyword. Certainly you can learn that keyword, you can learn its mechanics, you can use it so often that that becomes not a problem for you.

[00:03:12]
But the default reaction for programmers seems to be to get it confused, which is why there's so many questions on Stack Overflow about it. People saying, well I declared it with a const and then it changed, or it wasn't declared with a const, and it didn't change. I mean, it just creates perpetual confusion.

[00:03:27]
So much so that some programming language communities had so much trouble with it that the language itself, namely I'm talking about Java here, they basically deprecated the const keyword and introduced a new keyword in its place called final. Because const had this English language baggage attached to it, that said it's a constant, it's a thing that's not gonna change.

[00:03:49]
And now we're saying final sort of implies it's the final assignment of this variable. I guess that's helped the Java community, I'm certainly not a Java programmer. But they had to make that change because people were confused by it. And I've set up this entire course in the context of we want to communicate better with our code.

[00:04:08]
Why would we use a feature which has long historical precedent for confusing people? So that's where the real trouble that I have comes from. It starts out already in the negative, if you will. And with any programming language feature, with any framework feature, the question that needs to be asked is, does that thing carry its own weight?

[00:04:32]
Does it have enough benefit to overcome any potential downsides that it may present? Most of the time, I think we'd say that would be true. But with the const keyword, my claim is, it doesn't really carry its own weight. If it's gonna trip people up, especially the new readers of a piece of code, or people that aren't yet familiar with the thing, if it's going to have that strong potential to trip people up, that strong decades-long precedent for tripping people up.

[00:04:59]
Then it ought to provide a really substantial benefit to our program to justify its inclusion. And the claims of its benefit are I think, at best, weak. So for example, in this slide, we see a const declaration on line 2, another const declaration on line 3. And then of course line 8, since it's named that way, it sort of implies it's doing a side effect.

[00:05:26]
It's writing to a database or changing a record in the DOM, or who knows what it's doing. But the point that I'm making is that this is a relatively short block of code. It's only seven lines of code inside of the curly brace blocks. We're told many times that we should keep our blocks short, that we shouldn't be writing hundreds or thousands of line-long blocks, because it's hard for the reader to understand things.

[00:05:51]
My own personal kind of style guide, if you will, or what I try to keep is I try to keep no block, no function larger than what I can see on the screen at any given time. And at my general zoom level, that's about 20, maybe 25 lines at most.

[00:06:08]
So if it's longer than that, I'm immediately thinking to myself, I should be refactoring this thing. I should be trying to break it down into 10, 15, 20 line at most. I shouldn't be having 100-line long blocks. And I'll be honest with you, you can see a lot of my code, if you go on my Github, that breaks that rule.

[00:06:23]
So I'm not always perfect, in fact, I'm often not perfect at that. But it's a general guide for myself that I don't want to have these long, long blocks that are hard to read. So if you're following that sort of thing, if you're following what the general best practice is to have a short block, we need to understand that the idea of assignment is inherently related to the idea of lexical scope.

[00:06:46]
The idea of assigning to a variable is inextricably linked to the idea that that variable belongs to a particular scope. When we do const shippingCost on line 2, we have created a variable that exists only for the next six lines of code. It does not exist anywhere else in the program.

[00:07:05]
And that means that nowhere else in the program could possibly reassign it. We have a short block of code, and we have only a few lines of code that could possibly do the reassignment. So the typical argument is, well const signals intent. It tells the developer that's reading your code, you don't have to worry, it won't get reassigned later in the code.

[00:07:31]
But if we're following best practice, that's not very many lines of code that it's asserting anything about anyway. It's not as if we have tens of thousands of lines of code that we couldn't possibly as a human juggle, right here we have six other lines. And there's another way to say to the reader of your code, I'm not gonna reassign a thing, and it's to simply just not reassign it.

[00:07:56]
As matter of fact, if you're doing functional programming, don't assign at all. As little as possible, do assignments. So I'm not sure that the const keyword is actually providing all that much benefit, even in this best case scenario, where you're saying to the developer, hey listen. I'm not gonna reassign it, because most of the lines that could be reassigned are already clearly visible to you.

[00:08:20]
And you can see that it's not being reassigned. In these particular cases, since we're inside of a block, my preference is to use the let keyword. And I use the var keyword at the function level scope rather than the let, because it says to readers, and has for 23 years, this variable belongs to the entire function.

[00:08:41]
>> Kyle Simpson: So maybe assignment immutability isn't such a big deal. Maybe it isn't the problem that we really ought to be concerning ourselves with. But there is a much bigger deal that I think we should be concerning ourselves with. That's the question of value immutability. Because unlike assignments, which are lexically scoped by their literal definition, they are lexically scoped to generally a small portion of our program.

[00:09:08]
Values, especially values that are passed by reference, are completely portable. They can go anywhere in the program, and even beyond the program to other third-party code that is included and running. So if you take an array that has some numbers in it and you pass it somewhere else, you have to be asking yourself the question, what is going to happen to that value?