Managing Impurity Solution

[00:00:00]
>> Anjana Vakil: Let's look at impure render app first. What's going on here, is we're passing in the art we wanna render, calling Pure Get SVG on it, whatever that does. We're not gonna worry about that till 30 seconds from now [LAUGH]. And then we are doing this impure side effect of messing with the DOM.

[00:00:23]
>> Anjana Vakil: Yeah, so this is not a pure function because of that side effect. Did anybody have a significantly different impure render app than mine?
>> Speaker 2: I made it more impure by putting, [LAUGH].
>> Anjana Vakil: By putting in what, sorry?
>> Speaker 2: By putting art in from global scope rather than.

[00:00:43]
>> Anjana Vakil: Yes, exactly, so we could, for example, just do that still passes cuz we know there's impurity in this function. So yeah, let's use all the impurity, why not? The only reason I put it in as an argument here is because of a bunch of the other stuff we're gonna do later just to make it work nicer.

[00:01:06]
But yes, perfectly legit. Now let's take a look at Pure get SVG. Now is this making anybody uneasy here that I'm calling this a pure function?
>> Speaker 3: Part of me is at the ID setting, because then I can't recall it with a different ID and I'm just, I don't know, if I try to hit art SVG.

[00:01:29]
I can't have multiple art SVGs, I'm going to cause problems for myself later, but I know that's not exactly what we're going over here.
>> Anjana Vakil: No, sure, yeah, but so there is this weird thing of like, okay, the ID is essentially hard coded inside of this function. If I wanted to be able to call this multiple times to create different SVGs with different ID attributes, what could I do?

[00:01:53]
>> Speaker 2: Add an argument parameter.
>> Anjana Vakil: Exactly, add a parameter so that I receive the value of ID as an argument and assign it essentially, so then I would have to change this now my tests are failing to art, nope.
>> Speaker 2: The create element.
>> Anjana Vakil: It's probably looking to see if the-

[00:02:18]
>> Speaker 2: I think line five if you scroll all the way over to the end, there's ID.
>> Anjana Vakil: Right, I was doing that again for course reasons. Yeah, the tests aren't using it right, yeah, exactly, no, of course. I'm actually running the test, so I would have to do something like that.

[00:02:36]
>> Speaker 2: Yeah.
>> Anjana Vakil: There we go.
>> Speaker 2: Nice.
>> Anjana Vakil: See, this is why we program in community. Okay, [LAUGH] so yeah, so there are ways that we could make this a more flexible function. And that is exactly the type of stuff that we're gonna be doing a ton of as functional programmers.

[00:02:51]
We're gonna be looking later in the course at how to make the most flexible functions possible so that we can reuse them a lot, and we can recompose them as well to create the specific solutions we need.
>> Speaker 3: So we're creating all the SVG and everything, and we always know it's gonna be deterministic.

[00:03:11]
It's gonna come out to be the same, that's the core. We can reuse this function, and then the outside is where we're attaching it to the DOM, rendering it all this possible, calling the function.
>> Anjana Vakil: Exactly.
>> Speaker 3: Okay.
>> Anjana Vakil: And so, for example, I don't know, does my document have an element with id app?

[00:03:32]
So all of the impurity happens at this outer level. And in a way, this is like, if you have worked with react or any other framework, that essentially lets you just say, well, this data in my page, please, and lets the framework handle the actual rendering. That's what we're doing, we're pushing all of that impure rendering stuff into the framework, which is outside of my program.

[00:03:59]
And we're keeping the logic of like, deciding what value and attribute should be pure. We're keeping that deterministic and predictable. And so the code that I'm writing, if there is anything impure I wanna do, I'm gonna put it on the outermost layer, on the outermost function. And then I'm like I keep everything else as pure as possible underneath that, so that I can easily test and debug and so on and so forth.

[00:04:29]
>> Anjana Vakil: Sweet, and so this is really like, okay, so if there's one concept to walk away from this of course, whether it's pure functions. If there's two concepts, the second one would be the real world is not a pure function. Computers are not pure functions, although they are arguably deterministic.

[00:04:51]
But anyway, we'll talk about that later. But the fact of life that we need to do impure stuff in our work as programmers, because that is what we get paid for, is not going anywhere. So all we can do is box it in and make sure that we keep anything that might result in unpredictable things isolated away from the logic of calculating, like whatever our program is supposed to do, in this case, come up with an SVG.

[00:05:26]
So the work that we're doing here, and the walls that we're bashing our head against, around purity and like this is the whole thing of functional programming is how do we isolate impurity? How do we make sure that all of the real world messy stuff stays trapped in a layer where it can't infect the rest of the program, and by calling the pure function from inside the impure function, that's cool.

[00:05:58]
We don't introduce any impurity there. The inverse would be a bad idea, right? We don't wanna call an impure function, because inside of our function, we want to be pure, because that impurity infects the function, as we saw before. So this is the technique, we could stop here.

[00:06:17]
If you wanna do functional programming, make sure all the messy crap you're doing in your code happens on the outermost layer [LAUGH]. But there's a lot more gotchas to that and there's a lot more to say about in real world functional programming, how do you deal with stuff like reading files that you need the data of.

[00:06:34]
Or making that word requests and all that stuff, and how do languages that really don't allow impure functions, like Haskell, etc, like, how do they do it? Monads, but the core idea here, even if we're not like this is not functional code, this is still our exact same imperative code, step by step, but we're wrapping it up in a function, and we know it's deterministic and it has no side effects.

[00:06:58]
And we're taking all of the non deterministic stuff, and we're putting it on the outside.