What is Functional Programming

[00:00:00]
>> Okay, so let's dig in, what is functional programming? The word of the day, the phrase of the day. If you're anything like me, especially me when I was just starting out in programming a few years back, you heard this term functional programming. And it seems like it's very trendy, very cool, like all of these buzz words, and concepts, and fancy symbols, like stateless, and pure net, immutable, side effects, referential highroller functors, and monads that are super lazy, and like what?

[00:00:38]
And then there's this lambda, this weird triangle symbol floating around everywhere, and then all of the functional meetups have it as their meetup logo, and what does this all mean? You might be wondering, I certainly was. And yes, okay it is trendy, it got lots of mathematical terminology.

[00:01:00]
It is something that some programmers like to think is like super cool, and it makes them look fancy and smart. But that's not what we're gonna focus on today, what we're gonna focus on is understanding what the ideas behind functional programming are. So, one other thing we might know about functional programming is that it is a style of coding, a type of programming that some languages support and maybe some others don't.

[00:01:30]
So you might have heard about some functional languages like Haskell or Clojure. Maybe some other ones, like for the front-end, there's Elm. There's some languages that support multiple types of programming including functional, and let's say object oriented like F Sharp or Scala. And then there is JavaScript, which probably does not usually get described as a functional language, but is actually really wonderful for learning the basics of functional programming in my opinion.

[00:01:59]
And personally, when I was learning JavaScript, learning functional programming also helped me get better at JavaScript, and become a more productive JavaScript developer. Once I started learning some of those basic functional programming concepts, we're gonna talk in a moment about why functional JavaScript is a really nice fit.

[00:02:19]
So, one other way to understand functional programming instead of thinking of as style of writing code is as a programming paradigm. Where a paradigm in programming, or in science, or in the world can be thought of as a sort of like a worldview, or a mindset, or a way of understanding the world, what things are in it, and how those things behave or interact.

[00:02:48]
Now, functional programming is just one of many, many, many different types of programming paradigms that software developers have developed over the course of computing history. This is by no means an exhaustive list, there are tons of these. But there are two really main distinct paradigms that you might have heard about.

[00:03:13]
On the one hand on the non-functional side, we have imperative programming. We can think of imperative programming as understanding the world of computing as a series of commands. Where programs are a series of instructions, do this, and then do that, and then do this other thing. So a program becomes a series of commands that the programmer gives to the computer, essentially.

[00:03:41]
And one kind of sub paradigm of the imperative mindset is object-oriented programming, which you may have heard of as well, you may have studied or that maybe the paradigm that you work in every day. And what object-oriented programming is, it could be the subject of a whole other workshop, which we're not gonna get into.

[00:04:01]
But in object-oriented programming, we use concepts like encapsulation, where we have objects that keep internal values to themselves, and they can change those values. Which when we have values changing over time, we have something called state which we're gonna talk about several times today. And then those objects since they're encapsulated, they keep that to themselves, but they can talk to each other through messages that they pass by, for example, calling methods on other objects in the program.

[00:04:31]
So you have a kind of this message passing lifestyle where the world of the program is made up of these little kind of cellular objects that are little encapsulated units, and they behave by interacting with each other through messages. If you're curious about how that all works, I have a talk you can find on YouTube.

[00:04:52]
That's all about object-oriented programming, and maybe that definition that I just gave is a little bit different than what you might have heard before. Okay, now I said on the other side from imperative programming is what we call declarative programming. Which is a worldview in which instead of telling the computer this is exactly how I want you to do my bidding, like we do an imperative programming with all these commands, do this, do that.

[00:05:22]
In declarative programming, we declare, this is what I would like from you computer please. And we let the computer or the program figure out how it's going to do that computation or how it's going to get it to us. So for example, if you've ever written SQL queries where you essentially tell the database what you want back, but you let the implementation figure out how exactly it's going to join different data together, and how it's going to filter things, and sort things for you.

[00:05:57]
So the idea with declarative programming is to move away from this command oriented imperative style. And functional programming is one type of a declarative paradigm. So the question now is, what is it? If it's somehow related to declarative programming, so we're no longer giving commands, what is it?

[00:06:20]
What are we doing when we're writing functional programming? And that is what we're gonna be exploring today. I claimed earlier and I'm going to continue claiming that functional programming is actually boils down to one basic idea, seems too good to be true, right? But really, there is this one core principle from which everything else, all of these scary mathematical terms, all of the monade, and monoids, and all of the functors, and the referential transparency.

[00:06:50]
And all this stuff kind of boils down to a single idea which if we keep that in mind, and kind of use that as our north star to guide our functional programming, we should be in good shape to start to understand how all of these other terms, and techniques, and tools are kind of consequences of that.

[00:07:10]
Now, I would not have this understanding that functional programming is actually way simpler than a lot of academic textbooks make it out to be. Well, it not for an amazing community that I was really lucky to join when I was starting out in programming called the Recurse Center.

[00:07:31]
This is their logo, this little computer, you might have seen them around, you can read more about it at recurse.com. And while I was at the Recurse Center, one of the people there who is helping me learn programming was named Mary Rose Cook. And Mary Rose cook wrote this amazing article which you can find and it's linked in the materials.

[00:07:54]
You can actually click right through it or you can read it right here in these slides. She wrote an article called an Introduction to Functional Programming Which really boiled this down. That sure there's all these terminologies, there's all these scary mathematical notations, and things like that. But really all you need to worry about is a single idea.

[00:08:13]
So I strongly recommend that everybody go check out this recurse.com publication called Code Words, check out this article, and read through it after the course. It uses Python, so we're gonna be talking about JavaScript today. But what Mary and the Recurse Center taught me is that actually, functional programming boils down to a single thing, pure functions.

[00:08:39]
So that is what we're gonna be thinking about today. Pure functions, what are they? Well, you could say a pure function is a function like we're used to writing in code. But it's special in that it only takes its input in and that is the only thing, the only data that it looks at about the world, and all that it does is return its output.

[00:09:05]
So we could think about pure functions as only input in and only output out. That has some consequences that we're gonna dig into in a moment. You can think of a pure function in functional programming as kind of like a black box where you have some input like this green circle that comes in.

[00:09:26]
And once the function has done its computation, you get some output like this blue purple triangle. Now, when we write functions, typically day to day when we're not really thinking about what paradigm we're using, or we're not really trying to be functional programs, we're just trying to get our jobs done, or get our coding exercises done.

[00:09:47]
We often write functions that look a little bit more like this where it takes some input, maybe more than one in and returns some output out. But it also kind of communicates with the outside world. So it also might be reading things from the outside world to help it make its computation, like for example, what time is it?

[00:10:07]
Or what profile picture does this user have stored on their profile, or what is the airspeed velocity of a swallow? Things like that, that aren't direct inputs to the function, but the function may be uses to do its computation. And similarly, the function might send something back to the outside world other than its return value.

[00:10:31]
So it might do something like log a value to the console, or turn on a light if you're working with LEDs, or it might update your profile picture on some website. Even though none of those are actually the return value, the output of the function. That communication with the outside world that sometimes our day to day functions do, that's what we call side effects.

[00:10:58]
It's basically any time the function has any relation to the outside world other than through its input arguments and its return value. It is doing some kind of side effect, and that is what is not allowed in a pure function. So a pure function, to put it in another way is a function that does not have any side effects.

[00:11:22]
All it looks at, the only information it needs is whatever is passed in to it as an input, and the only thing it does in the world is return its output value. But let me suffice to say that with all these different paradigms, they all have their advantages and disadvantages.

[00:11:41]
Just like everything in programming, in software development, it's always a matter of trade-offs. And so each of these paradigms has something that it can kind of teach us about how to think about the world of a program, and how to conceive of the complex programs that we wanna write, how to break them down into smaller entities.

[00:12:03]
And I think that it is the best thing that we can do as programmers to learn lots of different paradigms, and to think of them as different tools in our mental toolbox, so that we can effortlessly switch between them when we need to. Now that is a lifelong work, that is a lifestyle that we were never done with.

[00:12:30]
But hopefully, by the end of the day, we'll have a little bit more of an intuition of what we like about writing code in a functional style. And maybe also an intuition about times when it's not so convenient. And especially in a couple of sections from now, we're gonna get into an exercise where we're really comparing imperative and functional programming.

[00:12:50]
And we'll get into those differences in a little bit.