Functional-Light JavaScript, v2 Functional Programming

Transcript from the "Functional Programming" Lesson

[00:00:00]
>> Kyle Simpson: Let's jump into our course on Functional Light JavaScript. I wanna explain just a moment, the title and then I'm gonna spend a little bit of time motivating this topic of functional programming. Because there's probably different reasons why you showed up or why you're taking this particular course.

[00:00:17] And I wanna talk about what my motivation is for teaching it, my approach. But just the title itself, I wanna make sure that we address this for a moment. So, first off this is a refresh of a course on Frontend Masters by the same name. The very first time I ever taught the topic was for Frontend Masters and I gave this course before.

[00:00:38] So it was the very first path I ever made at it. And now we're a year and a half or so later, I've written a full book on the topic, I've been learning a lot more about it. And so I've come back to refresh this topic, give a fresh set of eyes to it.

[00:00:52] In some ways, it's some of the same stuff that we talked about but in other ways, there are very different ways that I think about it and therefore, teach and share with others. I thought about calling the course functional lighter JS since we're updating it but that [LAUGH] sort of implies that we're getting less.

[00:01:09] So I will calling it the same thing Functional Light. But speaking of that name, what do I mean by functional light, what is that? You might be of the impression that the word light is intended to imply intro, or beginner, or easy path in. And I wanna change that particular notion.

[00:01:33] This is rigorous material and especially, if you read the book functional programming is not for the light of heart. But [COUGH] it does not have to be a cliff that somebody just throws you up against and you keep banging your face up against. That's what I had done for nearly a decade of trying to learn this topic.

[00:01:52] Some of you may have been like me, at one point or another you heard this term functional programming. The very first time I heard that term I thought, well that's cool. I use functions in my program, I'm already doing functional programming. And then it was years of realizing, no, I wasn't doing functional programming at all.

[00:02:11] I didn't even understand in a real true sense what a function was. And we're gonna spend a bunch of time even really trying to figure out what a function is and what the characteristics are that you might not have actually thought of. Cuz it really does start with that.

[00:02:23] As a matter of fact when I started writing my book, the very first chapter, the literally the first sentence [LAUGH] of the first chapter. I made this statement and then I pushed it up to GitHub because I write and push things up as quickly as I've written them or whatever.

[00:02:38] So I pushed up the first paragraph or two of this book. And the very first sentence said functional programming is not all about the function. And I knew I was doing something right because the functional programming police came out of nowhere, I have no idea that they even knew that I was writing a book.

[00:02:57] They came, descended upon me and told me, this is horrible why would you say such a thing, functional programming is all about the function. And they hadn't even given me an opportunity to explain the context of what I meant there. What I was really saying is functional programming is not all about the function keyword.

[00:03:15] So I clarified that to make [LAUGH] sure they wouldn't be so upset. It's not all about the function keyword. It is however, all about the function and about modeling, our applications in such a way that functions play a pivotal role in how data transfers through the application. And that will change the way you approach organizing your code.

[00:03:36] It should change it because if it's not changing it, then what are you wasting your time on? It should change it and it should try to improve. I'm gonna use terms like better and improve and we're gonna have to know even what that means. So I wanna get even into that before we go forward.

[00:03:52] I wanna make sure we're all on the same page here. [COUGH] So Functional Light is not some intro easy beginner but what it is is like showing up at the face of a cliff. And instead of having to figure out how to use the rock climbing equipment, there's somebody there to show you how the equipment works.

[00:04:12] You still have to climb the cliff wall but instead of figuring out the equipment yourself, you now have some instruction on how to get up the cliff. That's the proper way to approach this. It will be difficult. As a matter of fact, and we mentioned before that I have this book that's where you can find it on GitHub [COUGH].

[00:04:32] I'm trying to be very unassuming about this because my description there, I'm just talking about functional programming. I'm not really a functional programmer, so I'm not even qualified to write about it which is why I gave it this name, Functional Light. Because I wanted to distinguish that my approach is bottom up rather than top down.

[00:04:51] Most approaches to functional programming start with, okay, let's all learn about category theory and types and all of this notation. And then from there we can learn this and learn that, it's a top down approach. Now I took computer science and I still get lost in all of that notation and terminology.

[00:05:10] Time, and time, and time again I go to a conference and I'd say, this is the time I'm gonna sit in the functional talk and this is the time I'm gonna learn something. And to be honest with you there was this one guy at every conference that I did actually learn a little bit from, Bryan Lonsdorf.

[00:05:25] He's kind of my personal hero, especially on this topic. He has taught a much deeper and more authoritative course on functional programming here on this platform. He also has written about it: Professor Frisbee's Mostly Adequate Guide. He has been the beacon that has helped me figure out anything that I've known.

[00:05:43] But I would understand the first five minutes of Brian's talk, and then I was completely lost. So I'd be furiously trying to take notes and about five or six minutes in, I give up. Cuz he's using terminology like when you say something like a monad is just a monoid in the category of endofunctors.

[00:05:59] If you already know what those words mean, that is a very precise and crisp way to communicate a set of ideas. So I don't mean ti make fun of those words or the idea that those words matter, they absolutely do. But that's throwing a bunch of equipment at me and saying, figure out how to use that equipment.

[00:06:18] And even if I could figure out how to climb it, I probably wouldn't be doing it safely. So I think we needed a different way to start at this topic and that's what Functional Light is about, it's this bottom up pragmatic approach. We're uncovering the core principles or at least the things I think are core principles to functional programmers.

[00:06:36] But we're uncovering them from a more intuitive and less top down notation terminology heavy way. So, why functional programming? What is the motivation here, what is it that we're trying to improve and what does it even mean to improve? I wanna frame that discussion about functional programming around the debate or the contrast between imperative and declarative.

[00:07:03] I don't know how many people listening in will know exactly what I mean by that, so I wanna be very clear, what we mean by imperative versus declarative. Imperative code is code that focuses on how to accomplish a task. As a matter of fact, if we go all the way back to the beginning of programming computers.

[00:07:23] When it was done by one's and zero's on punch cards, that is the most imperative. We're literally telling it switch this bit from one to zero and that sorta thing. We're literally telling it exactly how to do its job. It's not interpreting anything, it's just doing what we told it to do.

[00:07:40] That's the perfect most pure example of imperative code. As soon as we started adding programming languages on top of the ones and zeros. Assembly language being one of the first representations of that. As soon as we did that, we started to create some abstraction where we were writing in a language that was more friendly to humans.

[00:08:00] And it was being interpreted into a language that the computer understood, the one's and the zero's. So it's slightly less imperative but still highly imperative. Assembly language, if you've ever seen it. It's like move this piece of data into this register and then move this here. I mean it's very, very imperative.

[00:08:18] And then we invented more programming languages on top of that. And within each of those tiers of programming language generations we added frameworks, and libraries, and patterns, and DSLs, and other things like that. To abstract the way more, the instructions that we wanna give to the computer from what actually happens.

[00:08:40] So, even the code that you write, even when you write a for loop in JavaScript, it's not nearly as imperative as it would had you been writing the one's and zero's of the assembly [INAUDIBLE]. It is more declarative, so this is not a binary, something is either imperative or it is declarative.

[00:08:56] Or rather a continuum, we've moving more towards the declarative, as we have been adding more to program. As we've been advancing the art of performing language design and framework design, DSLs and things of that nature, we've been moving more and more towards that. And you see some chiming examples of that [COUGH].

[00:09:14] One of the most common, that people will know these days, angulars, touted as a declarative framework of sorts because you declare in your mark up what you want to have happened. And angular figures out how to make it happen. So if imperative is focusing on how to make something happen.

[00:09:33] Declarative is focusing on what should happen and not how. That's the contrast. Now why does this matter? It matters because most of the advancements that we've made along this continuum to be more declarative, most of those advancements are there. Because it's easier to read and understand declarative code then it is to read and understand imperative code.

[00:09:56] As a matter of fact, we could sort of say the computer is better at the imperative part and we're better at the cognitive declarative part. That's what we're good at. So we've been, in a sense, improving the interface between us and the computer, so that we can say what we want to have happen.

[00:10:13] And the computer can figure out the best way to make that happen, the best how. There is no truly completely declarative, either just like the one's and zero's at one end, we're not doing that anymore. We're not doing fully declarative coding like on Star Trek where you just talk to the computer and you're like, analyze.

[00:10:33] And the computer just figures out what you meant by that, we're not doing that. And I don't know that we ever will. So, we'll always be somewhere on the spectrum. And each given piece of code needs to be at different places on the spectrum. Each different place in the code we have to decide, is it better for me to focus on more precisely instructing the computer, or is it better for me to focus on expressing my ideas?

[00:10:58] But as a general rule, the more declarative we are the more we focus on expressing the what instead of the how. The easier it is for somebody to come along to read later. And I wanna talk about this easier and better thing but I wanna caution you about an effect.

[00:11:18] This is not unique to me but I'm applying it to this particular domain. I wanna caution you about an effect that will happen as you start to move from imperative to declarative using techniques that we learn here. And using the stuff that you learn beyond this class in the book and in other people's books.

[00:11:36] I wanna caution you on this perception of readability problem. So as we move along the x axis from imperative to declarative, we start out at the beginning with a certain moderate level of readability. We feel like, I can mostly understand what I'm doing with the code. And you'll notice that is, as we move along the curve, we begin to see some improvement in the readability of the code rather early.

[00:12:08] And we're feeling really good about ourselves. We're like, wow. I'm really using some of this functional stuff. And I'm being more declarative and it's starting to make more sense. And then somewhere along the way, we begin to press that curve. And we begin to bring more of these ideas in and all of a sudden, we're bringing ideas in that are transforming our code in such pronounced ways that when we take a fresh look at it or when somebody else looks at our code.

[00:12:34] They're like, what are you doing there? And it can actually really start to go down hill and you start to get to the point where you can't even understand what your code is doing anymore, and you're like, why I'm I even doing this? And it's at that moment, I have found and not only from myself but others that many people bail and say, this is not working for me.

[00:12:56] Sometimes we blame ourselves, sometimes we blame the tool. We say functional programming is just poorly designed, it's too opaque, it's too thick with all of this stuff for me to possibly get there. And I would say that I have gone all the way down into that trough and begun to come out the other side.

[00:13:18] And I can tell you that the mountain climb is worth it when you make it through that valley. But I cannot promise you that that is an easy path to take. I don't have some easy path that gets you there without going through that trough. I wish I did, I'd probably revolutionize this space if there was some magic way to just make it so that you never have to struggle with that.

[00:13:44] But what I'm trying to do is encourage you that that climb is worth it, that that journey, that that path is worth it. And not to give up. And not to get lost in the disillusionment that can often occur. Now, that's not to discourage you because what we're gonna focus on today is that first part of the curve.

[00:14:08] In this course, we're gonna focus on the first part of the curve and trying to get those early winds from the most intuitive and pragmatic things that we can improve about our code. But I don't want you to think that that is where your journey ought to stop because I don't think it's where it ought to stop.

[00:14:25] And I don't think that you should never aspire to be a functional programmer. What I hope is that Functional Light is your tutorial on how to use the climbing tools. And once you graduate from Functional Light and you've read the book. And you feel very confident about that, your next mountain to climb is the real climb of real functional programming.

[00:14:46] So this is your path onto the mountain if you will.