Why Functional Programming

[00:00:00]
>> Kyle Simpson: We need to understand why functional programming. That's a really key critical thing and and let me even be meta about it. Why do we need to understand why functional programming? You're already here. You're already watching this course. That seems like it ought to be too obvious. You have some curiosity.

[00:00:17]
And I'm willing to bet that if we surveyed everyone that's watching right now, we'd get lots of different answers as to why you're here, why is this the time that you've chosen to invest. Why have you chosen this particular moment in your career? Maybe there's something happening at work.

[00:00:32]
Maybe there's a shift happening and you feel like you're getting left behind and you wanna keep up. Maybe you've been curious about it, maybe you're already super experienced and you're just listening to hear me trip up and make a mistake. And that's probably gonna happen, too. So there's a wide range of motivations that might be.

[00:00:49]
But I want to give you one that may not be obvious to you. I want to tell you that one of the biggest reasons why you should learn functional programming and why this should matter and why we need to discuss that, is because it is impossible, at least in my opinion, impossible for you to write functional programming in isolation.

[00:01:12]
It is impossible for you to go back to work tomorrow or the next day, and send in a pull request where you've rewritten a whole section of your code using some new technique that we learn in this course. And then all of a sudden, just magically, that's gonna land in the code and everybody's gonna be happy and thumbs up about it.

[00:01:30]
You can't take this journey up the side of the cliff face alone. You're going to have to convince the people that you collaborate with that there's value in the journey as well. So while you're sitting here watching this course, you need to understand that whoever it is that you work with now and in the future.

[00:01:49]
You're gonna have to be able to convince them to come on the journey as well. You're gonna have to convince them that climbing straight up the side of a cliff wall, which sounds crazy, is actually worthwhile, okay? That's why this conversation matters, why functional programming? I have some thoughts on why functional programming, but I'm sharing these because you're going to have to, almost in a proxy sense, you're going to have to share those with the people around you.

[00:02:15]
You're gonna have to convince them. One of the biggest reasons why functional programming and it's often touted, is that functional programming signals a shift or it signals a paradigm difference in the way that you approach code. And that can be incorporated in these ideas of imperative programming versus declarative programming.

[00:02:37]
Let's make sure we understand what those words mean, because I don't want to just throw words like carabiner at you and not have them have a definition. What does imperative mean? The good news is, unless you already are one of those unicorns who learned programming from the beginning, as a functional programmer, and if you are, I'm envious of you, okay?

[00:02:58]
But unless you are like that, then you're like all the rest of us, which is that you learned non-functionally, which is to say you learned imperatively. Imperative code means code that is focused primarily on how to do something. If somebody tells you, I've got a list of numbers that all needed to be added up and get a final total sum.

[00:03:24]
Just me saying that English sentence means, that almost all of you had the same code snippet that popped into your head. If you have any experience with programming at all. All of you probably conceived something like, I'm gonna set up an accumulator variable called Total. And I'm gonna for loop over the array, and I'm gonna add each element into the total and then return the total.

[00:03:46]
>> Kyle Simpson: And if that's the way that you thought about the problem, you're in good company because that's the way all the rest of us thought about the problem. And that's the imperative approach because that code, while it will work, and while it's familiar and while it's convenient, and while it's probably pretty performant, all of those are good things.

[00:04:04]
But that code is imperative because the future reader of that code has to read all of the code and, in a sense, almost mentally execute the code, before they understand what it's purpose is. They have to do that. They can't simply glance at this particular for loop and immediately know exactly what that for loop is doing.

[00:04:26]
They have to read it and execute a few iterations and then convince themselves. They have to infer from the code what it's doing. And you may think, well, that's not a big deal, that's what programmers do. We read code and then we write code, of course. Not a big deal.

[00:04:43]
Well it is kind of a big deal. It is kind of a big deal because it forces the reader to do something that they're not actually naturally gifted at doing. Guess who's particularly good at executing code. The computer. Who's not so great at executing code? Our brains, they weren't built for that.

[00:05:07]
So any time that you write some code that forces the person to execute it in their head just so they can understand it, it's code that's gonna be harder to understand. And code that's harder to understand is code that's harder to maintain, to improve, to fix. So what is declarative then?

[00:05:25]
If imperative is all focused, or almost all focused on how, declarative stands in opposition to that. Because declarative says, no, no, the how is not the important part. The important part is the what, the outcome. And even more importantly than that, why? I get this question a lot actually, when people talk about code comments, or maybe not a question, but people will just assert things.

[00:05:50]
Some people will say, code comments are evil. Anytime you have a code comment, it means that the code is terrible. Code ought to self document itself. I think that's nonsense. Certainly there's a nugget of truth in there but we've taken it far to the extreme. Code doesn't need to self document itself.

[00:06:09]
Code needs to tell a story, it needs to communicate, that's for sure. But it is a need to self document. There is a purpose for code comments. They're not an excuse for not caring about your code. A lot of people will go to the other extreme and say, what does it matter how bad the code as long as there's a code comment, and I explained what I was doing.

[00:06:32]
That's good enough. Actually, it's not good enough because most of the time, code comments are out of sync with the code. [LAUGH] So it's even worse than it not being there. A bad code comment is worse than no comment at all, because then the person spends twice as much time spinning their wheels.

[00:06:51]
But on the topic of code comments, and I'm using this as an illustration point of the reason why declarative is useful. On the topic of code comments, my response is always, no, no, no, you don't have to remove all comments, but your comment should not duplicate the narrative of what the code is doing.

[00:07:10]
Don't have a line of code that says i plus plus, and then put a code comment that says increment i. I can see that it's incrementing i. I don't need a code comment to tell me that, okay. That's not the important reason for that code comment. Here's what I wanna know from your code comment.

[00:07:29]
Why are you incrementing by one? What is magical about one as opposed to incrementing by two?
>> Kyle Simpson: That might be useful information, that I want you to tell me. That's what a code comment should focus on. It should focus on the why, not the what, and sometimes maybe it needs to focus on the how if it's particularly confusing, if there's something particularly hard to understand.

[00:07:50]
But even in those cases, that's a clue that maybe I could work on improving that code, so that ideally all of my code comments focus on why. But we can go even further than that and say, what if your code made it obvious why it was doing something.

[00:08:10]
Well then, you don't need a code comment there. So I'm not saying no code comments. I'm simply saying shift our perspective from imperative to declarative. Focus on, let's allow the system to do what it does best, it figures things out best. And let's focus our code on why we need that, why we need that what outcome.

[00:08:30]
What is it going to accomplish? And why is that useful to us? That's what our code should look like to whatever extent we possibly can. And to the extent that we can't, that's what our code comments should be explaining. Are you following me? So we wanna shift in this direction and that is one of the biggest reasons for why functional programming, because functional programming is, by its very nature, more declarative.

[00:08:57]
You notice that I'm couching this in relative terminology because there really aren't a lot of absolutes. It's not like there's a little check box that says, functional programming is definitely declarative and everything else is definitely not. That's not how it is. It's a spectrum. It's relative. From whatever perspective you come at that question, a piece of code could both look imperative or declarative.

[00:09:20]
If you've done lots of very declarative coding and then you look at something that's a little less declarative like a four loop, you're gonna say that's imperative. But if you've done nothing but ones and zeros or assembly language programming, and then you see something like a for loop, you're gonna say, wow, that's pretty declarative.

[00:09:38]
You follow where I'm coming from? So it's perspective, it's relative. But to whatever extent that we can shift the focus for the reader of our code towards the declarative away from the imperative, it's gonna be easier for them to understand, not only for them but also for us, our future selves.