Transcript from the "Functional Programming Concepts" Lesson
>> Brian Holt: Now we're gonna do some functional programming. And in my opinion, most the stuff that I have shown you so far is very useful for interviews and little else for the most part. It's useful to know because it's useful to make those trade offs in your head. But they're actually not really gonna help you in your day to day programming.
[00:00:23] However, this functional programming stuff I'm about to show you, does help you every day. This made me a much better programmer once I learned how to do this stuff. Or even if you're doing like stuff like Mongo DB app reduce, that's all based on the same concept that we're doing here.
>> Speaker 2: One quick question on the last-
>> Brian Holt: Sure.
>> Speaker 2: Section from Dan. He says it looks like you're hashing the value, not the key. Should it be the key or the value?
>> Brian Holt: It should definitely be the key. Am I not doing that? Let's go back and look.
>> Brian Holt: Well to be totally honest with you, the key is both the key and the value because we're doing a collection. This isn't a map, this is a collection slash set. So the key and the value in this particular case end up being the same thing.
[00:01:25] Good question though.
>> Brian Holt: Okay, so functional programming.
[00:02:12] And we don't want it to modify parameters either. So basically, if I give you the same input 10 billion times, I wanna get the same answer 10 billion times. That's the expectation with avoiding side effects. This is really, really nice because now this function is very testable. I can rip out this function and test it as much as I want.
[00:02:33] And I can be guaranteed that this function does what it's supposed to do. And that if I inserted it in some other scenario, it's only taking in input and giving out output, right? It's not doing anything else. And so thus, it's very easy to know what goes on with a function.
[00:02:47] So that's why avoiding side effects is very important. Second, we're gonna focus on higher order functions, which is basically the idea that we're gonna have functions that apply other functions. So if you remember back, we were doing that test method when we were doing the tree, right. That's actually a higher order function that's taking in that test method and applying it, right.
[00:03:11] So now at that point we can pass in different testing functions and get the same results, right? That's a higher order function, that's taking in one function and applying it. This will make more sense once we start talking about the actual higher order functions that we are gonna do it with.
[00:03:29] And thirdly, we're gonna be transforming lists of data. Which is something very, very common to functional and eventually reactive programming, that all you're doing is taking the one list, doing something to it and giving you back a new list of transformed values.
>> Brian Holt: [COUGH] What's really cool about functional programming is we begin to describe what we want as opposed to how we want it to happen.
[00:03:56] And I think that's a really powerful concept, it's declarative versus imperative programming. We're declaring that this is gonna happen, then this is gonna happen, then this is gonna happen, and then this is what I'm gonna get. As opposed to say step one is this, step two is this, step three is that.
[00:04:10] That's the idea behind functional programming is that, it's what I have right here, it's maintainable, it's composable, and it's easy to reason about. And I make these different kind of building blocks, and the building blocks can be rearranged and used in different order and used in different ways and recompose with each other.
[00:04:27] And then I can test each building block super well, so that I know when I go back to reach for this other component, it's already built and it's already super well tested and it's just very maintainable and very happy.