Functional-Light JavaScript, v3

Function Arguments

Kyle Simpson

Kyle Simpson

You Don't Know JS
Functional-Light JavaScript, v3

Check out a free preview of the full Functional-Light JavaScript, v3 course

The "Function Arguments" Lesson is part of the full, Functional-Light JavaScript, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Kyle distinguishes between an argument and a parameter, explains what unary and binary functions are, and connects it all by explaining the idea of a function's shape.


Transcript from the "Function Arguments" Lesson

>> Kyle Simpson: Okay, let's shift our attention, we're still talking about functions but, let's shift our attention specifically to the arguments, the parameters that functions receive. And by the way just clear up some terminology. Parameter and argument are often used interchangeably. They are technically different. The generally accepted definition here is that a parameter is the thing in the function definition.

Like if I say function, add number, and then I have x and y, the x and the y are parameters. What is an argument then? That's the value that gets passed in when you call the function. So if I later say add number 3, 4, the 3 and the 4 are the arguments that get assigned to the parameters x and y, respectively.

Arguments get assigned to parameters. So when I use arguments here, I'm referring to the things that are being passed in. But we also are encompassing in that umbrella the parameters that they get assigned to, we're talking about the inputs to the function. We wanna look at the nature of the inputs of those functions.

All right, so if I have a function called increment, that takes a single input value, in this case x, and it returns a value back, and in this case it's the sum of x and y. There's a special term to describe that shape of function. And I'm gonna use this idea of shape throughout the rest of this course, okay?

And I want you to understand I could be talking about things that are much more formal like type definitions, but I don't think that's useful for us. So I'm gonna use more informal language here to describe the shape of a function. Okay, and here's what the shape of a function is.

The number and the kinds of things you pass into it, as well as the number and the kinds of things that come out of it, that's the shape of a function. We're being less formal than restricting ourselves to particular type language, okay. We'll talk about type signatures. So the shape of a function that takes a single value in and gives us a single value out, that shape has a special kind of name we call a unary function.

And if we look on line seven at a function called sum, that takes an x and a y, as x and y formal parameters. That takes two inputs, so the shape of that function is a little different. It takes two inputs, still returns one output, we call that a binary function.

>> Kyle Simpson: So we have terms unary and binary. They could sound scary, but they're actually pretty straightforward. They're just describing the shape of the input signature, if you will. What do we expect to be able to pass in, and importantly, what do we expect to be able to get out?

>> Kyle Simpson: And it turns out that the shape of functions is super critical. The functional programmer is almost obsessed with the shape of functions. Very similar to if you were playing with a set of Legos, and you were trying to build up a model, it would matter if this piece fit on top of this piece, wouldn't it?

If they didn't fit, you couldn't use them together. So if I have a bunch of functions in my application. And their shapes are not compatible, they don't fit like Lego pieces don't fit, then they're not gonna work together, are they? The shapes of our functions matter, and it matters so much that in the authoring of our functions, we're constantly thinking, what is this shape going to imply to my future usage of it?

Am I gonna restrict myself to only using it in certain cases, if it looks like this? For functions that we are in control of, we want to care about the shape. When I say in control, I mean, we get to decide the design of the function like what it's called and what it takes and what it returns.

For functions that we decide we want to be very cognizant of that chain and what it will imply, what it will create as an effect when it's being used. For reasons that you won't fully understand now but you will begin to get as we go further along, functional programmers tend to prefer unary functions.

Single input, single output. And their next favorite kind of function is a binary function, two inputs single output. And I'd say probably 95, 98% of all functions you'll ever see in a good functional program will be of one of those two sorts. It's probably like 70, 30 unary versus binary.

There is a term to describe all of the other functions, those miscellaneous ones that take 3, 4, 10, 20, whatever. We call those enary functions. They're vastly less common because the more inputs a function has, the harder it is to make it work with other functions, harder is to get the shapes to fit.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now