JavaScript: The Hard Parts, v2

# Generalized Functions

Check out a free preview of the full JavaScript: The Hard Parts, v2 course:
The "Generalized Functions" Lesson is part of the full, JavaScript: The Hard Parts, v2 course featured in this preview video. Here's what you'd learn in this lesson:

## Will uses a trivial example to demonstrate how parameters can be used to extend functionality.

Get Unlimited Access Now

Transcript from the "Generalized Functions" Lesson

[00:00:00]
>> Will Sentance: Now we move on to a cool part of functional programming, which maybe some of you thought the functional programming talk I gave here. But let's start off with why do we even have functions? Why do we even have them? Let's see why. Let's create a function 10 squared, takes no input, returns 10 by 10, and for once I want the exact wordings of these functions.

[00:00:19] So, Ryan, what's the exact wording of this function? Function 10 squared take no input returns, what'll be the exact wording Ryan, here? We're gonna use the traditional style. By the way, I should say, we're gonna see an ever more popular style of declaring and saving functions in a moment in a little bit.

[00:00:38] But for now, let's use the traditional function declaration style. How do I declare? How do I save a function 10 square? What keyword do I tell the computer, I'm gonna save a function?
>> Speaker 2: Function?
>> Will Sentance: Function, pretty good, excellent. There it is, function. What should I call it?

[00:00:54]
>> Speaker 2: 10 squared?
>> Will Sentance: Yeah, does it take any inputs?
>> Speaker 2: Does not.
>> Will Sentance: No, so empty parenthesis. And then in the body of the function Ryan, we've got?
>> Speaker 2: Returns 10 times 10.
>> Will Sentance: Yeah, brilliant, Ryan. Ryan is disappointed with this function I can tell already by his tone of voice.

[00:01:15]
>> [LAUGH]
>> Will Sentance: Your tone of voice Ryan, I don't blame you. We call it, we get what Ryan? It's gonna evaluate to what everybody?
>> Speaker 3: 100.
>> Will Sentance: 100. Great, but do we write this function?
>> Speaker 3: No. [LAUGH]
>> Will Sentance: I love this function, this is a terrible function. What about 9 squared?

[00:01:37] Ethan, what would I do to change this or no? Can't edit functions once I've saved them. Wanna build 9 squared. Off I go. What would I write, Ethan?
>> Speaker 2: Declare a function, 9 squared.
>> Will Sentance: Do I have to write, so you suffer with me, and we realize why we have functions.

[00:01:52] I'm gonna write it out again, yet okay. No. Go ahead, Ethan. This is gonna be more wiping down the board, you know that?
>> Speaker 2: Returns 9 times 9.
>> Will Sentance: Actually, the fact it takes so long to wipe the board down is something of a metaphor for our premise.

[00:02:06] That's equivalent to editing and writing code, it's very appropriate. Yeah, do we write this function, Ethan? No. No, we don't wanna rewrite stuff like this. But what about, there you go, 9 squared? I'll confirm my little friendly, look at that little guy. So he's so perturbed, there so perturbed.

[00:02:25] Who knows? There perturbed, perturbed. Add an 8 squared function, 125 squared function people. What principle, everybody, are we breaking? Does everyone know? Yeah, DRY. Don't repeat yourself, right? This is a fundamental principle in programming, write as little as possible. And not just from a premise of words per hour per dollar.

[00:02:48] But, in a deeper sense, we don't wanna be rewriting code when we don't have to. Because it gets much, much harder to track and maintain what we're doing if we do so. We're breaking our principal DRY, Don't Repeat Yourself. So, what could we do here, instead? Turning to, Peter, what could we do here, instead, besides writing out a function 9 squared?

[00:03:10] A function 8 squared? What is the thing that's the same, each time? So, what could we do, instead, here, Peter?
>> Speaker 2: The squaring is the same. So, we could generalize the input.
>> Will Sentance: Beautiful, fantastic, we can generalize the function to make it more reusable. We could build a function like squared, no, we save the code of it, but we leave a little bit of that code TBD.

[00:03:31] Specifically, we leave exactly what data, what thing we're gonna multiply by itself. Cuz they're all the same. 9 by 9. 10 by 10. The odd number multiplied by itself. If instead I can leave the thing I'm gonna to multiply blank until I run the code, I write the code once of multiplying them by itself.

[00:03:51] And then run it and dynamically at the moment of running the function, turn it into 10 by 10. Turn it into 9 by 9. Turn it into 8 by 8. Literally, the 10 is gonna fly and replace num, I'm gonna get 10 by 10. The 8 is gonna fly, I'm gonna get 8 by 8.

[00:04:09] This is our premise or co premise of functions. Making code that we can write once and then reuse again and again with different values, different data. That is what a parameter is for. But wait folk, what if, here we go. Parameters, placeholders, meaning we don't need to decide what data to run out functionality on until we run the function.

[00:04:31] Folk, what if it weren't just the data that we could leave TBD in our function? What if it weren't just leaving a blank to fill in with numbers or strings or rate? What if we could also leave a little bit of our code, TBD? Leave a little bit of our code only to be determined once we actually run the function?

[00:04:53] Leave a little bit of our functionality to be left blank? And when we run the function, fill that functionality in? That would make our functions super reusable, super general. And that's exactly what higher order functions are gonna do. We may not want to decide exactly what some of our functionality is, until we run our function.