Transcript from the "Pure Functions" Lesson
>> Will Sentance: The functions are run data through one by one. The start is called point free. Point free starter writing code, sometimes ironically known as pointless. To start a writing code, we write out a list of functions. And we do not explicitly state their arguments and their returned values in that line in which we use them.
[00:00:23] We do not call them with our, we don't explicitly state the calling of them. Instead, we rely on just listing them out and knowing the structure by which they're executed, which is just input output, output of that line, input of the next line. Output of that function, input of the next function, output of that function, input of the next function.
[00:00:42] This is point free starter coding. And again, increases readability. Do, do, do,do. Not, do with that value and then that value do, maybe those two values do, and then those three values have a side effect over here. It's do, do, do, do. Every line there I know exactly what it's doing.
[00:00:59] No looking up the rest of my code, it's having effects elsewhere. It's only effect is that very next line. And I get to remove the worry about arguments then because its only input. I don't need to explicitly state input because I know the only input is the output of the previous line.
[00:01:11] So why would I state it? It's there implicitly. It's known as point free style of coding and increases readability, once you embrace it, enormously. All right. Easy to debug. I know exactly the line of code my bug is in, firstly it's got a label. I can go and look it up in my call, there it is.
[00:01:29] There's a label of the line. And it's only consequence is that line so a bit of the question is, how many bugs can I really get? That's why you hear the functional programming evangelists talk about why I never get any [LAUGH] bugs, I've moved beyond bugs. I don't know if this true, but it does come from the sense that most bugs come from an extraordinary end to end dependency tree of every single line, every single line affects all of the lines.
[00:01:55] And functions help you with that, you reduce it to 10 dependency, 10 lines affecting 10 other lines. But we know that in reality we often have consequences outside our functions. So, most the time really, all lines affect all other lines and this is the absolute profound complete opposite.
[00:02:19] It's the extreme opposite. All right. Okay, now I want to talk a little bit about that notion of every single line being entirely self-contained, having no impact outside of it's single line. There's only going to be sort of light comments here. It's not amazing amount of stuff to say about this.
[00:02:41] But even though it's incredibly significant in functional programming, but we're kind of seeing it as we go. Functions as tiny units to be combined and run automatically must be, not highly predictable, completely predictable. I must be certain their only consequence is that line because I'm literally not even going to have arguments in return values explicitly stated.
[00:03:01] I'm not going to go and look at that add free function most of the time. It benefits only consequences that result into the next line. Pure functions. Well, here we go, we rely on their evaluated result to pass the input to the next unit of code automatically. Any what sort of side effects we're gonna see in a sec what that means, will destroy this, would destroy everything we're doing here.
[00:03:21] It would undo everything we're doing. I need it to be that when I run this function, it's only consequence is its output in that very line and then automatically rely on the structure of reduce the path that output into the next line. Any other consequences in global memory, for example, would undo everything.
[00:03:39] My code is no longer readable. This is no longer saying run probably two, add three, divide by five. It's saying run add three, and maybe do something else randomly inside there or somewhere else in my code, it would undo everything. So we have to have functions which are known as pure.
[00:03:54] Their only consequence is that evaluated result. It relates to referential transparency. But referential transparency is a sophisticated mathematical concept beyond the scope of what we're doing here. Well, it's beyond the scope, but its pure functions are related, but let's focus on pure functions. Let's walk through this little block of code here and just make sure everyone knows what I mean by a side effect.
[00:04:16] I don't wanna dwell on this a bit too long, because it's so short and yet it's so significant, but I think it ties into everything we do. So it's not maybe we don't need as long on it because we basically been building up to it the whole time.
>> Will Sentance: Okay, good, keep it small down here. Line one, let's have a little mini app here. Just a sort of mini app with the memory here. Line one, Michael, keeping it simple here, what are we doing?
>> Michael: We have the label num, and it's assigned the value 10.
>> Will Sentance: Yep. The next line, Reginald?
>> Reginald: Add three.
>> Will Sentance: He is the only person ever, who, as soon as he sees me he goes straight into answering the question, which is fantastic. It is actually a function add three. I'm gonna draw it like this, actually. Input of x, return value of x + 3 and mystery stuff.
[00:05:14] That it does inside. Let's run it. I probably should have assigned its results somewhere but whatever. Add three with the input of seven, everyone, so we can reinvigorate, three o'clock brand new.
>> Will Sentance: Very nice.
>> Will Sentance: Into it we go. And in the local memory, x is set to what, Virginia?
>> Virginia: 10.
>> Will Sentance: We're running at three.
>> Virginia: Sorry, 7.
>> Will Sentance: She's right, 7.
>> Jasmine: Global.
>> Will Sentance: Yeah, it goes out. This is literally out the side of the execution context, and it does what to num?
>> Jasmine: Adds 1 to it.
>> Will Sentance: And then we have our 7 plus 3 which will be 10, which we return out.