Pure Functions Solution

[00:00:00]
>> We are hopefully really excited to dig into these pure functions or are they? Or are they? That's what we're gonna be finding out. So hopefully everybody had a chance to go through this notebook. And if anyone is again having any issues with accessing the course materials on observable, they should work.

[00:00:19]
It should work in all browsers and whatnot. But if anyone is having struggles, please let us know. So let's talk about these pure functions, shall we? Okay, we're gonna go through these one by one and just make sure that if there's any questions about why we labeled it as pure or not pure.

[00:00:37]
Or any asterisks or what if sir, those kind of questions that we have a chance to go through them. So let's just take a few minutes to go through each of these functions. All right, this get date function. What do we think and folks can shout it out pure or not?

[00:00:55]
>> Not.
>> I heard it not, nodding I see nodding so it sounds like everybody thinks it is not pure has a high five raise hands, it is indeed not pure. Can anybody recap without looking at the explanation right now, why this is not pure function, get date.

[00:01:17]
>> I thought it was pure originally.
>> Okay.
>> Everytime you call it, you get a new date.
>> Everytime you call it you get a new date. Is that what someone else had unmuted is that what a someone else's was about to say?
>> Actually the date is a part of the outside world.

[00:01:36]
It's not an argument. So that is why. Otherwise we always give new arguments. So those are also new. Is a part of the outside world. It's not an argument.
>> The date is a part of the outside world. So we are asking something about the outside world here.

[00:01:51]
And yes, so when we call this different times like on different days, let's say if we call this tomorrow or in a week or in a year, assuming we get to 2021 [LAUGH]. If we call this multiple times at different times when the data has changed because that is something about the outside world, we will get a different result.

[00:02:10]
So we can't be guaranteed that this is deterministic, we can't be guaranteed that if I call get date with the same arguments in this case, no arguments that I'm always gonna get the same answer. In fact, I'll get different things for the return value. So yes, we have kind of a little bit of an interaction here.

[00:02:26]
The question was is it not the constructor of the data object that's MPR as opposed to the function get date itself. And so again, this is one of those cases where we need to know something about the functions that we're calling within our functions and their purity, right?

[00:02:43]
So this date, when I construct a new date, like this like we do in get date. I have an impure function because I can call that multiple times on different days and still get different answers. So yes, there is introducing impurity into our function. There, because this function is not super pure.

[00:03:08]
So let's contrast this I think it'll it'll bring a few things about get date to light here. If we look at get workshop date. We'll leave that one up there too. What about get workshop date? What do we think pure or not?
>> Pure.
>> I heard pure.

[00:03:25]
>> Pure.
>> Pure, pure. Lets try pure. Woo hoo. So what's the difference between get workshop date and get date? So yes, this get workshop date function is deterministic, it always gives the same result. If I call it tomorrow, if I call it in a year, if I call it in 10 years, assuming JavaScript hasn't changed dramatically since then, I should get the same result.

[00:03:53]
And again, there is a little bit of interaction here going on with this date, the capital D date in JavaScript because we need to know something about that and what it's gonna what its behavior is gonna be. But the way that date constructor works if I pass in these arguments, I'm always gonna get back the same date.

[00:04:13]
And that's gonna give me the same date string. So this get workshop date function even though it takes no inputs. It's always going to give me the same output regardless of when I call it. So it is deterministic. I always know what this function is gonna return if I call it with the same arguments, no arguments in this case.

[00:04:33]
Okay, moving on. How about this two hex function? Pure or not? I heard pure, I'm seeing nods for pure, Woo hoo, this is pure. Again we've got a function which depends on essentially only its input arguments. We are using some built in JavaScript features here, like some of these string methods but those also are not going to introduce impurity into this function.

[00:05:16]
So we're always gonna have a predictable deterministic output, yeah. So the question is if I have a function that's taking in an array. And returning a random element from that array, is that a pure or impure function? No, I'm gonna return that right back over to the room.

[00:05:35]
What if folks think pure or not, if I'm returning a randomly selected element?
>> Up here, the random number generator is a side effects.
>> I heard not pure the random number generator is a side effect. So, what do we know about randomness? It is not deterministic, right?

[00:05:55]
That is it's kind of the opposite of deterministic. If a deterministic thing is something that we know what its answer is gonna be, then a random thing is something that we have no idea or maybe we have some idea probabilistically but we can't be sure. So randomness is a side effect.

[00:06:14]
Randomness is not functional randomness is not deterministic. And so randomness is another one of those things where when we're working with randomness, we need to think about it as a side effect and is one of those world affecting operations that we kind of pushed to the edges of our program.

[00:06:30]
So working with the randomness and functional programming is a whole topic that's a big can of worms that is certainly super interesting to dive into but for suffice it to say that in the code that we're gonna be writing today to really wrap our heads around functional programming.

[00:06:44]
We're gonna be doubling down on determinism and we're gonna be avoiding things like randomness. So randomness would introduce impurity in functional programming. We want to be deterministic and we do not want to change the outside state of the world except for returning a value, that is the thing that we are concerned with doing to the outside world is giving it our output value back.

[00:07:12]
So yes, we want to make sure we're being deterministic and make sure that all that we are doing is returning that output value. So how about this RGB to hex function pure not pure?
>> Pure.
>> I hear pure. It is indeed. So similar logic as last time with our two hex function in this case.

[00:07:45]
However, we do we make this we make use of this to hex function, right which again is a little bit. Maybe we need to think about it and make sure that we know whether to hex is pure and deterministic or not. But since we already said that to hex is deterministic it is pure.

[00:08:04]
In this case, we're not introducing any impurity, and so we've still got a pure function. How about set color pure or not? I hear not. I hear some knots. I hear not pure, not pure. Whoo hoo, great work. All right, can somebody tell me what is not pure about this function?

[00:08:31]
>> It's not returning anything.
>> Well, we saw one of those big red flags. It's not returning anything. There's no return statement. So in JavaScript, it's returning undefined but again, red flag because what's important in pure functions is what they return. So if I don't even care enough to put the word return in there, I probably have a pretty good indication.

[00:08:49]
It's not a pure function. Anything else that makes us think it's not pure?
>> It's accessing the DOM.
>> It's accessing the DOM, yes. So this function is setting the color of a element from our document. So this is a side effect. This is something that it's doing to the world other than returning a value, which again, we don't even have a return statement here so we're not returning a value.

[00:09:17]
Instead what we're doing is updating the world somehow. So that is a prime example. Color pun not intended [LAUGH] of a impurity of a side effect in that function. Okay, moving on how about read JSON file pure or not feel like we're on a game show.
>> I think not impure.

[00:09:42]
I hear not, I see thumbs down, I hear impure. And it is indeed not pure. Can somebody recap why?
>> It's fetching the data from an outside URL, and then,
>> It fetch,
>> It's probably it's returning. All right, fine. So that's why.
>> It's fetching the data from an outside URL.

[00:10:13]
So that is something that is coming in from the outside world into the function, not pure. And also, what happens if the data at that URL changes or maybe that resource goes away and the fetch fails. What happens then? Well, we're probably gonna get a different result [LAUGH] than we did when it was working.

[00:10:37]
So we have non determinism as well. So this is again, these are real warning signs or red flags for functions that are not pure. Is if they're looking at something in the outside world, then because the outside world is always changing, we might not have a deterministic pure function.

[00:10:55]
>> Is it also a red flag that the file name input was never used?
>> Is it also a red flag that the file name input was never used? That is probably also interesting because it's actually not operating on the file name that was passed in. This may also be instructor oversight but let's imagine that file name was that this was replaced and I can actually do this right in observable, what about now?

[00:11:30]
>> Impure because the file, I mean the content of the file can change.
>> So we have a still maybe it is impure because the content of that file could change. Yes so in this case, it is looking at the input. Unlike the previous version which may be instructor error but even though it's looking at that input, it's using this fetch to find something from the outside world.

[00:11:55]
Which might have changed, might be different, might not be there, might give us an error we don't know. So again, that's why these impure functions are less predictable and they're harder to debug, you'd have to really like, make sure that you've handled all those error cases. They're harder to test.

[00:12:13]
And so, even though even if we're passing in the file name anytime we're asking the outside world for a resource or looking outside of the function for information, that is not pure.
>> Are all asynchronous functions impure by definition because you're returning a promise that later needs to be resolved.

[00:12:31]
I think anything you're doing asynchronously is non deterministic because if it was deterministic, then you wouldn't need to return a promise in the first place. Is that correct or am I.
>> Interesting question are all asynchronous operations in JavaScript impure. Because we need to wait for those promises to resolve.

[00:12:51]
What about a case of a really long running calculation that perhaps if I have some kind of like distributed system and part of one of my processors is doing a long calculation and I'm waiting for that to come back. Well, it depends again on like that calculation and what it's doing.

[00:13:12]
So I, this is an interesting one and asynchronicity in JavaScript always opens up cans of worms. And again, JavaScript itself is not necessarily the way JavaScript runs is not necessarily like the most pure functional environment. However the operation that we're doing asynchronously, it might not be an impure operation.

[00:13:40]
In this case, it's grabbing something from the world. But maybe it would just be a super long computation that I'm waiting to complete. And using this await, I'm essentially pausing my function from doing anything else until that is done. And so if that is a deterministic pure operation and if my function is also being deterministic and pure, then I don't necessarily have any impurity introduced into my program.

[00:14:05]
But I feel like we want to ask folks like Kyle Simpson and Brian Lonsurf, what they think about that question. They are much more Asynchronous JavaScript pros then me, okay moving right along so we said read Jason file was not pure. What about write Jason string? Pure or not?

[00:14:30]
>> Pure.
>> We should be confident if we've already clicked all of these buttons, all right so what makes right Jason string pure while read Jason file is not pure. What right Jason string is doing is taking in an object and outputting a string based on that object now, Jason stringify.

[00:14:53]
We probably have to look into a little bit make sure that we know whether it's deterministic or not, but in this case, that is going to return the same string if I was give it the same object. However, there is a little bit of an asterisk on this.

[00:15:07]
Can anybody think of a condition in which this might introduce a little bit of trickiness to this situation? Has to do with the object or passing in.
>> The object is an array maybe?
>> Okay, I heard maybe if the object is an array or what if?
>> If object is changing?

[00:15:27]
>> If the object is changing, right, so if the object is a regular JavaScript object or regular JavaScript array, both of those are mutable types of data. So somebody could come along and mess with the contents of my object. And so then if I call this function on the same object because it has retained its identity but the contents of the object.

[00:15:53]
Inside have changed then I might get a different output when I call this at different times. So again, this is why it's really important in functional programming to work with immutable data that can't change. And we're gonna look at how we can do that in JavaScript, which doesn't by default have a lot of immutable data.

[00:16:09]
We're gonna look at that in depth later today. The truth table functions here exclusive are real quick. Let's do it pure or not.
>> Pure.
>> I heard pure, boom. Hopefully it's clear that this will always give me the same result because I can depend on those logical operators in JavaScript to always give me the same thing if I give them the same truth values.

[00:16:34]
All right now what about this compute truth table where I give it an operator and I get out a table of all of the different permutations for that operator, pure or not?
>> Pure.
>> I heard pure and I see thumbs up indeed. Now, there's a little bit more going on in this function than in some of the functions that we've seen so far.

[00:16:59]
But let's think about it. We're taking in an operator and that is really the only thing that the value of this result depends on. And then we are returning that value, which in this case is an array of objects, and we should get the same object no matter how many times we call it with the same argument.

[00:17:26]
However, there is also something about this function that feels a little fishy. Feels a little not functional. Does anybody get a tingling sense, yes?
>> The operator argument could be a function which does affect the outside world.
>> Okay, the operator could be sneaky and pass in a side effecting impure function here.

[00:17:51]
That is one way that we could introduce impurity into this function. And so again, that's why in pure functional languages, you're sort of guaranteed that all of your functions are pure. And that's a nice guarantee to have in JavaScript. We don't have that guarantee. So we have to be disciplined about it.

[00:18:09]
But yes, good point.
>> That is also that we are mutating table inside.
>> We are also mutating table inside of the function, great point. So this is I've been talking like immutable, immutable, immutable data immutable data, we're not doing that here. We're pushing things into this table.

[00:18:30]
We're changing table. So this feels a little un functional however, since we're doing it inside of the function and we're not communicating with the outside world at all and nobody else can access that table and mess with it. While I'm doing this computation, we're not introducing impurity. However, this isn't really a functional style of writing code.

[00:18:51]
It's still pretty imperative. Still pretty command oriented. So in a moment we're going to look at how we could do this in a more functional style. Great points. Okay, how about show a truth table? I think everybody is gonna, yell and one voice. Not pure exactly. So, just like before, we said console logging is not cool console table, which is a fun fun one.

[00:19:25]
If anybody hasn't used it, try it out. Console table is also spitting out something to the console. That's not pure and again, no return statement. Red Flag not pure function. Okay, great job.