Same Input, Same Output

[00:00:00]
>> Kyle Simpson: Okay, what about this function, getId? And we have an obj parameter, and it looks like basically all we do is access the id property on that obj and return it back. So let me ask you this question, if I were to call getId over and over and over again with the same object, would I get the same value out every time?

[00:00:26]
I see different answers, some of you nodding your heads, some of you shaking your head. So think about it this way. How sure would you be if you saw this function, if you saw this thing, which is either a function or a procedure. If you saw this in your application, how sure would you be at its predictability?

[00:00:46]
That every time it's called, it's always gonna give the same response?
>> Kyle Simpson: Well, one question you would ask is, does that object get mutated at some point? Well, let's say you had answered that. Let's say in all places that you saw getId being called, it was always the same object, and the object was never the subject of any reassignment.

[00:01:07]
Then would you say, yeah, I feel pretty confident? What if I reveal a bit more of the program and I say, what if that object doesn't have a regular property, but rather has a getter? And what if that getter returns random numbers? All of a sudden now that I've revealed more of the program, our confidence level tanked, right, down to zero.

[00:01:33]
You see what I'm saying is that it's important for you to be able to see the entire program. Or better than that, it's important that you be able to see all the relevant parts of a program. The more that you can use the techniques that we're talking about in this course, to reduce the surface area where these non functional things can occur, the easier it is for somebody to read, understand and ultimately to rely upon.

[00:02:03]
We want the reader of our code, which is not just other people on our team, it's also our future self, tomorrow and the next day, when we don't remember why we wrote the code that way. Whoever it is that's reading the code, we want that person to be able to tell, yeah, I know we can trust that.

[00:02:18]
It's definitely pure. Because if they can, then they can move on to other stuff. If they can't trust it, they can't move on. So the thing that I'm getting at here and this is super critical for you to get. The thing that I'm getting out, the principle that I'm getting at here, is that pure function calls act in isolation.

[00:02:40]
In other words, given the same inputs, they always produce the same output. That's another side of the Rubik's Cube. If you're looking for another component of the definition of a pure function, it is to say that a pure function is one where every time we execute that function with the same inputs, we absolutely, positively, know that it will always give the same output.

[00:03:04]
And here we know it won't, right? Here we know by definition, if I call that same line five over and over and over again, we know we're gonna get different answers every time. Otherwise, something's really wrong with our random number generator, right?
>> Kyle Simpson: So that's the key, is that we want to design our program so that as many of our function calls are like that as possible.

[00:03:26]
As much as possible, we want our function calls to behave as pure, meaning that every time we give it the same input, we're gonna get the same output. There's more to the Rubik's Cube but we'll come back to that as we continue our discussion.