Immutable Data Structures

[00:00:00]
>> Kyle Simpson: But again, that still only tells something about data structures that never need to change. What do we do with data structures that do need to change? Well, you can't treat all data structures as immutable data structure. As read only data structures, some of them are going to have to be mutable.

[00:00:24]
And here's the real counter intuitive thing. When you have the need for a mutable data structure, that is one that is not read only, what you actually need is an immutable data structure. Let me say that again, because it's really strange. When you need a mutable data structure, what you actually need is an immutable data structure.

[00:00:52]
So what am I talking about here, what do I mean by that? An immutable data structure, is one that allows not no mutation, but rather structured mutation. Structured controlled intentional mutation, as opposed to just willy nilly make an assignment statement and create a side effects somewhere. It's the next level from a read only, you should start by asking, is this ever going to need to mutate in any way, shape, or form?

[00:01:23]
If so, then I don't use a read only, I need to do something immutable. But if it never needs to change, then just stick with the plain, simple, read-only data structure. We only step up to this immutable data structure, if it needs to mutate. So what exactly is an immutable data structure?

[00:01:42]
It is a representation of the data structures that we are used to dealing with. We're used to dealing with data structures, like arrays where we can access things at index positions. We're used to dealing with things like objects, where we can access things at named property positions. It's things like that, it's data structures like that.

[00:02:02]
But where you don't have access to the actual underlying data structure, what you have only is an API to access it. And the API, creates a layer of control that prevents unexpected changes to the data structure. Specifically what an immutable data structure says, is, unless you switch it into a special mode that allows this.

[00:02:27]
So by default it's not, if you switch it into a special mode you can literally go in and muck with it if you have like a performance problem that you need to deal with. But in a general state, an immutable data structure says essentially you cannot change the data structure, you can only create a new data structure with the change having been applied.

[00:02:51]
Similar to what we did, a couple of slides ago when I made a copy to the thing and then I added the status field to it. It's similar to that concept, it says, listen, I need to add something to it. And the response from the API is, okay, but here's a new data structure with the change applied.

[00:03:07]
I'm not gonna let you modify the previous one. And the reason I'm not gonna let you modify the previous one, is that somebody else in the program might be relying upon the previous state of that object.
>> Kyle Simpson: They have to opt in to saying, I want your version of the object.

[00:03:25]
You don't get to decide, process order, that you're gonna affect something at a distance somewhere else in the app. You could return the new order, the processed order with the status field, and allow the caller of your function to decide what they wanna do with that information. But you don't get to mutate it from afar.

[00:03:44]
That's what I mean by saying that immutable data structure creates a control mechanism, it creates a controlled intentional way for the mutation to occur and by default, it simply says let's make a whole new object, a whole new array, a whole new list, a whole new object, a whole new map, whatever the data structure is, make a whole new one of those with the change having their plight.

[00:04:06]
Now the question becomes, how could that possibly be performed, how could it possibly be performed for me to make a only copy this array or only copy of this object every single time I need to make a change. Because the kinds of objects and arrays that we're talking about the need to be mutated probably need to be mutated a lot.

[00:04:26]
Not once or twice, not 3 or 10 times but like thousands of times a second. So the ante is high for if I'm going to change this thing over and over and over and over again so often, and I'm creating all these new ones and throwing all the old ones away at worst.

[00:04:43]
I mean, at best, I just have a bunch of garbage collection. But at worst you consider all the CPU churn of making all those copies over and over again. And this is where the real power of an immutable data structure comes in. Because the way immutable data structures are designed, is designed specifically with this optimization in mind.

[00:05:03]
In theory, in functional programming, we just say, no you don't make a new thing. You don't make a change to a thing, you make a new thing with the change applied. But in practice, that means real cost like garbage collection and CPU. And so, it is the job of an immutable data structure to mitigate that real practical cost, so that we get closer back to the theoretical benefit of what an immutable data structure is.

[00:05:30]
So, if you use an immutable data structure, what it's actually going to do is not create a whole new copy of the object when you try to change a property, but rather make a new object with the new information in it and internally, have a pointer back to the previous one.

[00:05:46]
It's actually a little bit like a get repo, where every time you've committed something you're just storing a deaf compared to what it was before. And immutable data structure is essentially conceptually like a get data structure, where each new object in the chain that you've created is just a deaf on the previous object.

[00:06:07]
Its stores internally that there's now a new property or that a properties been changed or something like that. And so, you're not paying nearly as much of the performance penalty CPU and you're not paying the garbage collection penalty. In the general sense, there's certainly corner cases here and it's why immutable data structures cannot allow you to opt-in for time period you can sort of crack it open, make some changes and then lock it back together.

[00:06:32]
Those things have to exist because sometimes we have performance bottlenecks that we need to deal with, but in the general sense, we want to just use the data structure in that conceptual way and allow it to abstract away those performance optimizations for us. So, how do we get immutable data structures?

[00:06:50]
We do not at the present time have immutable data structures natively in JavaScript. There have been a couple of rumblings from some people on TC39, that maybe someday that will happen. But you need to understand that when I say, when somebody says, yeah, somebody on TC39 has talked about maybe it happening?

[00:07:08]
That means that we might get it a decade from now. That's not, it's gonna happen in a few weeks, or a few months. The timelines that we're talking about here are, well, it's been talked about for the last five years, and now there's a first proposal. And then four years later they vet it, and now it's finally landing.

[00:07:25]
So we're not talking about this sort of stuff landing natively in JavaScript any time soon. But it's at least encouraging that some conversation has started about it. Some people in that realm have started to say, maybe this would be useful for JavaScript to have built it natively. And there would be a huge benefit to the language being able to highly optimize these sorts of things that we're talking about.