Value Immutability

[00:00:00]
>> Kyle Simpson: Value immutability is a much more important question. If we were trying to come up with some sort of rating system here, I'd say 99% of the problems that we face come from a value being mutated in a way that we didn't expect. There's some global state object, that has 1500 properties on it.

[00:00:21]
And somewhere some weird obscure piece of code, change two or three of those properties in a way that we didn't expect, that's a value mutation. It has absolutely nothing to do with whether you use the const keyword or not. So value immutability is the big problem. 99% of the problem comes from value immutability or value mutability rather and only 1% of the time at best does it ever come from reassignment.

[00:00:47]
As a matter of fact, and I'm being completely honest with you. As a matter of fact based upon my own sort of introspection about my processes and code. Never once, not a single time has there ever been a case where one of the bugs that I was trying to fix was, oops, I reassigned a thing that I wasn't planning to assign.

[00:01:14]
That's never once been the problem that I've had, and I'm not saying that that's never been a problem for anybody. I'm sure that const exists because somebody somewhere reassigned a thing. But in 25 years of programming experience across a variety of languages, I've written I can't even count how many bugs, I'm way better than all of you at writing bugs, I'm good at it.

[00:01:35]
And of all the bugs that I've written, never once has the problem been, oops, I meant to leave x alone and instead I should have written y or something, that just isn't generally the problem that I face. And so I'm skeptical as to whether or not that assignment problem is really so widespread.

[00:01:55]
And I think we're not getting the proper attention on the value mutability problem, did you have a question?
>> Speaker 2: I was saying, the only example I've ever seen is doing a for loop, and then accidentally reassigning i when you use two, four loops or whatever
>> Kyle Simpson: That's a great point, right?

[00:02:11]
So like yes you could definitely accidentally have a variable updated inside of a for loop and then it throws the for loop off. Some people do that on purpose though like write for loops where they skip or go back and I have written code like that before, and it's always been a pain in the neck to manage and debug later.

[00:02:30]
It's always been a terrible idea, but I'm glad you bring up this point because that's an example where it theoretically could be a problem and guess what? Const doesn't solve that problem for us, because you by definition have to update that incrementor in your four loop. So you can't declare it with a const anyway.

[00:02:49]
So yes it's a problem, but it's not a problem that the cost key word is solving for us. Let's take a look at some examples of value mutability and how we can address this question of value mutability. So here I'm creating an order of details object and I'm conditionally adding some stuff in.

[00:03:09]
So I need for this thing to be able to mutated because I need to run some other conditions, and maybe update some properties or things, like I am doing on line 7 through 9. And then line 11, I pass that object and because it's an object, it's passed by reference.

[00:03:24]
I pass that object by reference into this process order function. Now, do any of us have any idea what process order is doing? Well we don't see it here, it's not local. So the answer is, no. We don't know what process order is doing. Can we go and look at all the code in processOrder and figure out?

[00:03:43]
Sure, but if there was something in this block after processOrder, that was relying upon orderDetails. We now automatically would have to have the suspicion, if we're paying attention, we have to have the suspicion, did something change about the orderDetails object? And if that isn't our intuition to ask, then it is almost certainly gonna be the source of a bug at some point.

[00:04:09]
One of the things that we do as functional programmers is try to predict where the bugs are gonna be, and avoid them before they occur by using patterns where they can't happen. And passing a value by reference, where somebody could accidentally or intentionally change a thing in a way that we're not expecting is like putting up a giant neon sign that says, please create a bug here that I haven't planned for.

[00:04:34]
>> Kyle Simpson: And this is why functional programmers take this so seriously. This is why immutability is one of the most critical topics and I think often under covered topics in all the functional programming. Because values get passed everywhere, we pass arrays and objects and functions all over the place.

[00:04:52]
And we should be asking ourselves every time we pass it, how do I know that that isn't gonna change in a way that is gonna create a bug in my program. When I pass the number 42, or the string hello world, I'm not worried cuz I know the language already protects me, but when I pass an object in array, I don't have that same level of guarantee.

[00:05:12]
So even without going and looking at the processOrder function I'm gonna make an assertion that the reader of this code could benefit from some sort of process or convention. That would allow them to know they can trust the orderDetails is not gonna get changed.