Transcript from the "Composition Utility" Lesson
>> Kyle Simpson: There are ways to extrapolate composition to a very general sense. And we are not gonna try to go very deep down that rabbit hole cuz there's actually a whole bunch of complexity here. That I have not personally found to be very useful in my programs. But I do just want to take you slightly into the rabbit hole, so you understand a little bit of how that mindset works.
[00:00:22] What if I wanted to create myself a slightly more generic utility, a composed utility, or rather I'll call it a composed you two utility. Which composes just two functions and it makes some assumptions about what arguments are passed. What if I wanted to make that sort of reusable utility?
[00:00:40] I could declare compose two function as I'm doing here on line nine, it takes a function one and a function two. And you'll notice that the first thing it does is create a new function then it returns back. Uh-oh, that's a different pattern than we've seen so far yet.
[00:00:55] That's a pattern that's gonna harken forward to what we're talking about when we talk about closure. The ability for comp to continue to access fn1 and fn2 at a later time, that's closure. So we'll see that a little bit later, but we are making a function as a result of calling compose2.
[00:01:30] Sucks, right? There's hope, I promise. On the next slide we're gonna see there's some hope here, but that's the old-school ugly way of doing it. And then we have arguments.shift and arguments.shift. I'm simply taking the first two off of the array and passing them into fn1. And its result and then I'm taking the third argument and passing in to fn2, okay?
[00:01:56] This was a way of cheating, saving some space for some slides. You might've chosen to sign those out into separate variables and pass them in, that would've been entirely fine. But I just making array and then I shift some things off that array. And you notice here that I made some assumptions, I assumed that you passed in two and only two functions.
[00:02:13] And that you passed in three and only three arguments and that you wanted the first two to got the second function. And then the result of that plus the third one to go to the first function, I made some assumptions here. Now, when you choose to make utilities like this, you can create any sort of utility your brain can come up with.
[00:02:36] What a functional programmer does is look at principles of mathematics, principles of programming logic. And say what are the most common patterns for how people compose stuff? And in fact, all functional programming is literally, it's a turtles all the way down sort of thing. It's, at this most basic level, let me define a pattern that's really very commonly used.
[00:02:57] Here's how we compose some stuff and then we make a slightly higher wrapper. And that's how those two things get composed. And then, now that I have things of that, when I want two of those to compose. That's how they normally compose, that's really all of what functional programming is.
[00:03:26] Don't make a pattern just simply because it looks cool or you've learned some new trick or something like that. Make one of these compositional patterns. Because it's something that you're doing over and over and over again and it's gonna help you. And by the way, you might end up discovering for yourself some of those very common compositional patterns.
[00:03:45] That have those fancy names, like monads and functors and all that other stuff, okay? Cuz that's all they've done in functional programming, is observe the most common of those patterns and make utilities for them. All right, so compose2 we pass in the function multAndSum. And then when we call multAndSum down there on line 21, you'll notice that it does correctly for us.
[00:04:06] It produces our 17 value resolved.
>> Kyle Simpson: Any questions about composition so far?
>> Speaker 2: All right, well I've got a question.
>> Kyle Simpson: Yeah.
>> Speaker 2: Why do we turn a function comp instead of just a function?
[00:04:45] And I know there's probably a bunch of people listening that'll be like. [SOUND] I don't like you, you should use arrow functions or whatever. That's a whole other side thing that we don't want to get into today. I just simply gave it a name because in a stack trace that word will show up if I have an error.
[00:05:00] If I didn't give it a name it wouldn't show up, that's a basic point. You'll see a whole bunch of places where I don't give them names. Cuz I'm cheating or I'm trying to save space on the slides or anything like that. So, it's definitely a do as I say [LAUGH], not as I do sort of thing.
[00:05:12] But, I do try to have the discipline of always naming my function expressions, yes?
>> Speaker 3: Actually, just a quick comment. On your previous slides you add five plus the multiplication and then everyplace you're actually adding the five afterwards.
>> Kyle Simpson: Just in my comment I say it in the opposite and the reason I do that is to motivate Why the parenthesis are necessary for order of operation.
>> Speaker 3: Okay.
>> Kyle Simpson: I wanted the numbers to be strictly increasing, three, four, five, because that's pleasant to people. So that's basic.
>> Speaker 3: Okay.
>> Kyle Simpson: Yes. You're right. You're right. Is there a question? Yes?
>> Speaker 4: There is question about random values. It seems even wrapping those wouldn't make them pure, it's like wrapping a random number generator?
[00:05:58] Would you be able to-
>> Kyle Simpson: [SOUND], is a random number generator a pure utility?
>> Speaker 4: Yeah.
>> Kyle Simpson: [LAUGH] That is also going down a rabbit hole. So, Pseudo random number generators are based upon a seed, which is a state. And if that state can be repeated in some way, if it is a seatable system.
[00:06:18] And it changes based upon that seed, that's an impure system. So, I guess at a very basic sense I'd have to tell you yes, random numbers would be impure.
>> Kyle Simpson: Say the question again, I'm sorry.
>> Kyle Simpson: [SOUND], okay, so functions is value is when most people say that. They're talking about functions as first class citizens, first class values with closure.
[00:07:03] And the question then is, is closure more closely related to functional programming? Absolutely, closure's a very important piece of functional programming. On the other hand, I have used a ton of closure without even remotely having programs that look like functional programming. So closure is not only a functional programming concept.
[00:07:24] But is absolutely, positively, without a doubt one of the most important things that comes from functional programming.