Understanding Functional Composition

[00:00:00]
>> Anjana Vakil: So when we talk about functional programs [LAUGH] there's a hint right there in the terminology. In imperative programming or object oriented program, well, imperative programming. What is a program made up of? A bunch of commands. Maybe those are grouped together into things like procedures or impure functions, but that's what the program is made up of.

[00:00:24]
In object oriented programming, the program is made up of not those kind of pure individual commands, but that imperative logic is wrapped up in these things we call objects, and that's what the program is made up of, a bunch of objects. In functional programming, a program is just a function, or perhaps it's better to say it's a bunch of functions all used together to do whatever computation our boss wants us to [LAUGH].

[00:00:58]
So when we think about a functional program, we are thinking about a function. The question is, how do we make a useful program that's just one function? Well, we do that by taking a bunch of smaller functions that do smaller bits of that program and composing them into one.

[00:01:19]
And so this is kind of a very basic illustration of that. We talked about having a pure function that just takes in one thing and returns another thing. So maybe we have a f here that's like, given a circle, give me the equivalent triangle of the same color.

[00:01:37]
And that output is just more data, which means it's ready to be an input to a function. So we can just keep passing. Input becomes output, which becomes input, which becomes output, which becomes input, which becomes output. So, if I have two functions, one of which doesn't change the color, but changes the shape, and the other of which doesn't change the shape, but changes the color.

[00:02:01]
If I pass a shape through both of them, I will get the changed shape and the changed color. And this is a composition of those two functions. And this is the only kind of little bit of a gotcha that you want to keep in mind here is that this is equivalent to essentially, what we're doing is we're calling f on x, and then we're calling g on that.

[00:02:32]
But the idea here is that in our pipeline, we think about it kind of left to right, but sometimes when you're writing this encode. We have to kind of mentally flip flop to right to left, which as we said, at least here in the West, where we often are very conventionalized to left to right thinking just as a little small, little gotcha.

[00:02:58]
You just wanna think about which functions being called first, and in the parentheses execution, whatever's inside is gonna be called first. And you also might see another way of writing function composition that you might remember from math class. Just like a little circle that thing that goes between f and g.

[00:03:19]
So you sometimes might see another functional programming notation, a different type of notation that says f dot g or like f circle g means the composition of f and g, which is equivalent to this. So you might see slightly different. It's like visual jargon, I don't know. Okay, so for example, and this is where it starts to become clear how our partial applications can be reused.

[00:03:49]
Earlier we had endectifier, in this case, we're gonna make an ender, and what that's gonna do is take in an ending like rocks or y'all, or [LAUGH] and it's going to return a function. And this is now we're getting into sort of pipelines of arrow functions, which is again getting closer and closer to the syntax you might see in more purely functional languages, should you ever decide to abandon our best friend Java's.

[00:04:21]
Just kidding. But so this function ender is, well, the function that is returned is gonna take in an input and then smoosh them together. So that means that this blue part is a closure, essentially, this is just a separate way, a different syntax for writing that nesting. So within this second arrow function, we have access to the outer scope as well as the current scope, and you can extend this to as many different layers as you want.

[00:04:57]
And in fact, the lambda calculus, which is the theoretical underpinnings of functional programming. It's a mathematical system for computation. That is what Alonzo church invented in the 30s, which became all of the lambda logo to functional languages we see at meetups today, whatever. You can actually do this, the type of things that you would do in super hardcore, original academic old school functional programming with just like arrow function after arrow function there's more resources about that in the epilogue.

[00:05:43]
Okay, so given this ender function, I can create a function called a door, which is gonna say, I love that thing, that thing rocks, right? Or I can create an announce like, hey, y'all, that's what I just said or I can create an exclaim function that's going to make everything align in my email, cuz I write emails with like 80 million exclamation points, if you ever send me an email, correct get ready for exclamation points.

[00:06:13]
Also I'm terrible replying email, so what we wanna do. Let's say, it's create like I wanna be able to easily hype up any tech topic I want. So I'm gonna create a hypeUp function that's gonna take in some kind of thing that I'm excited about and it's going to pipe it through all the three of these functions in order to get the final output.

[00:06:48]
So in this case, I hype up js, I get JS rocks, y'all. I hype up FP I get FP rocks y'all. And the only tricky bit here is don't forget that the order in which those endings are gonna be applied is not the same as the order left to right of what we will see in our source code, right?

[00:07:17]
So the last thing that happens as I add an exclamation point, the first thing that happens is I add rocks. Then what that JS rocks gets passed in to announce and so then I get JS rocks y'all dead tone, no excitement. And then that result gets passed into exclaim, and now I get JS rocks y'all with the excitement that we all deserve and crave.