Function Naming Semantics

[00:00:00]
>> Kyle: But there's more to it than it just takes inputs and does something and returns another value. Because if I took some inputs x and y and then just on line 2 I said like return 40. I'm gonna go out on a limb and say that wouldn't really in the truest spirit be considered a function.

[00:00:21]
>> Kyle: It would take inputs and it would return a value, but it really wouldn't be the spirit of a function. And to understand the spirit of a function, we really have to get back to the math. Now I promised I'm not gonna teach you a math course, we're just gonna dip our little toe into this math just briefly so that you can understand the spirit of functional programming.

[00:00:42]
Does anybody remember this kind of stuff in like eighth grade. The way I remember this is the TI 85 graphing calculator where we plug the thing in and drew pictures and stuff, okay? I remember this kind of stuff and I remember it used to look like y equals 2x squared plus 3.

[00:00:58]
I remember for months learning about these things, and just randomly coming up with numbers that meant absolutely nothing. They were just completely abstract, not concrete at all. And then we pulled out a graphing calculator and wow, all of a sudden this thing actually meant something concrete, it meant a drawing, that looks like, a u.

[00:01:23]
But I wish at that time and I wish now the kids that are learning this stuff, they're not using graphing calculators anymore probably, they're just using their phones. But I wish that somebody would say hey, guess what there's a concrete thing that's happening, which is that you're taking an input value.

[00:01:42]
In this case an x coordinate, we're gonna interpret the input value as an x coordinate, like the input value one. We're gonna put it into this thing called f(x), which is the function of x, I wish somebody said to me, hey, how you do like programming this kind of the same thing, like you put an input and it's gonna give you an output.

[00:02:02]
Nobody connected that dot for me at all I wish they had, cuz I've been a lot further along as a programmer if somebody connected it to this kind of stuff. But I remember plugging in the number one or the number two or the number three and getting these other numbers out.

[00:02:16]
One gives me the number five, and two gives me the number 11. And I remember, if you did a bunch of those dots and then you literally connected the dots, it would draw this same parabola. In other words, the output value is interpreted as the y component of the coordinate.

[00:02:38]
The input value is interpreted as the x coordinate, and when you take the input and the output together, we can interpret their meaning as a parabola.
>> Kyle: So what is a function? A function is a relationship between the input and the output. There's a semantic relationship between what I put in, and what I get out.

[00:03:08]
>> Kyle: If we would write this in JavaScript, we could just write function f and passing in an x and get back some other thing. But what would be a better name for that function,
>> Kyle: How about parabola?
>> Kyle: To describe to the reader of our code the relationship, the relationship is that if you put in an x coordinate, you're gonna get a y coordinate out.

[00:03:38]
That's why I said a slight ago that just returning 40 isn't really the spirit of a function because there's no relationship between the inputs and that output. That doesn't mean that if something returns a number, then it can't be a function. It just means that it matters if there's an obvious relationship between the two.

[00:04:00]
And if you're making things that don't have an obvious relationship between the input and the output, and that happens far more often than we realize. If you're doing that, you're not really accomplishing the spirit of functional programming.
>> Kyle: The goal here is to create relationships that are obvious to the reader of our code.

[00:04:20]
So, a function is the semantic relationship between input and computed output. Here if I make a function called shippingRate, the name of the function tells you the semantic relationship. If I put in size, weight, and speed, I'm going to get a shipping rate back out. That's what it's for.

[00:04:47]
>> Kyle: That's what functional programming bases itself on, okay? That everything that we use, some people metaphorically refer to them as Legos, like if you're playing with Legos, or whatever. Every Lego in our app, [LAUGH] has to have a name that describes a semantic relationship between the input and the output.

[00:05:11]
You have lots of functions, aka, procedures in your app, probably tens of thousands for some of you. How many of them, if you go and look at the name of the function, would you be able to understand the name of the procedure, rather. How many of those would you be able to clearly understand the relationship between the inputs and the outputs?

[00:05:32]
How many of you even produce outputs? Probably not that many, most of them probably do a lot of other things. Really useful things like writing to a database and blah, blah, but not a lot of them probably return you a value.
>> Kyle: So you have to put some special sunglasses on if you were to start looking at the code around you with this question of, is it a function or not?

[00:05:58]
Is it taking an input, and by the way, no input is a valid input. It doesn't have to have a number, the absence of an input is valid input. But is there a semantic relationship between what I put in and what I get out? And by the way, undefined is a valid output, as long as there's a semantic relationship to the input.

[00:06:19]
If I have a function who's job is to take an object and try to get a certain property off of it. And that object doesn't have the property, the proper, correct semantic return value would be undefined, would it not? That's entirely consistent with functional programming.
>> Kyle: But there has to be an obvious semantic relationship or we're not doing functional programming.