This course has been updated! We now recommend you take the Functional-Light JavaScript, v3 course.

Check out a free preview of the full Functional-Lite JavaScript course:
The "Wrap Up" Lesson is part of the full, Functional-Lite JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

Kyle wraps up the course with a review of the “Functional Lite” concepts he covered and some of his own thoughts on functional programming in general.

Get Unlimited Access Now

Transcript from the "Wrap Up" Lesson

>> [MUSIC]

>> Kyle Simpson: We started with basically not a lot of assumption about functional programming and we observed side effects. Side effects are when a function does something in addition to it's direct effect. And in addition to it]s direct return value it has some other effect. And that can be as simple as printing something the console, or as complicated as changing some state, changing some variable, in the other parts of our program.

[00:00:27] That's complicated not because if that function relies on that variable, we have to know, how many times the function's been called to be able to predict its outcome, but it's also complicated because if there's a variable hanging out in free space, that our function's relying upon, somebody else can change that variable and change out from underneath.

[00:00:46] It's like pulling the rug out from underneath you, changing what you expect. So that's one of the fundamental motivations for functional programming, is to eliminate all that complexity by doing what we call what?
>> Kyle Simpson: What's the opposite of these side effect functions?
>> Speaker 2: Pure.
>> Kyle Simpson: Pure functions. Pure functions operate only on the stuff that they were given.

[00:01:08] They have a direct return result if necessary. So they don't have any side effects in the outside world, which means all of that complexity that I just talked about becomes a non issue. Can you write an entirely pure program? Yeah, theoretically, yeah. It's gonna do anything? Not observable.

[00:01:30] [LAUGH] The fundamental definition of observation is a side effect. So we're gonna have to have some sort of cheat in there, and as we talk about functional programming languages, they have for example, in Haskell, they call it the IMO nav. It’s a special exception in there that allows you to do some IO in a nonfunctional or non-pure way.

>> Kyle Simpson: In JavaScript, we have a lot more freedom. Languages like Scala are the same way, more freedom, we can choose as much or how little of functional programming we wrap in. So after we talked about pure functions, we talked about composing functions together. So if you had an impure function you can wrap a function around it, produce a pure interface.

[00:02:12] And now you've preserved the notion of purity and we pass in the universe. And then we can compose multiple pure functions together. By instead of assigning the end result to some variable that some state that can be changed, simply calling the result of that and passing it into some other function.

[00:02:28] And we can do that manually by the call signature, or we can create compositional patterns that we know will take two functions, and compose them in some specific way. So we talked about, I called it composed two a way to specifically compose to functions and assume two parameters to each one.

[00:02:47] So that's one way of defining a composition plan. After we talked about composition we moved in immutability. We talked about not only immutable bindings. And immutable values but more importantly, the usage of values in an immutably sufficient way. So we had utilities that could produce a list that was changed in place or produce a whole new list.

[00:03:13] We actually started to see that in JavaScript didn't we? We saw the difference with something like slice, that doesn't change the array in place, it produces a new array, a new list, that's a subset of the previous list. So using the principles of immutable values, we create a new value every time we create a new list every time rather than mutating a list in place.

[00:03:38] After we talked about immutability, we moved into a discussion of closure. Closure being a way to wrap state around, wrap a value, some state in a function and then that function can move around and any time we call that function, we can get that state back out. Then we talked about recursion.

[00:03:56] Different ways of using recursion. Then we moved into our list operation. And I hope by this point you now have all those little fundamental legos. Those building blocks. So start using some of the principles of functional programming. But without being overburdened by all the traditional academic terminology and understanding.

[00:04:17] That is not to disparage those things and to say, that functional programming is bad. I think it's fantastic. I've been at this 17 years and every time I have tried to learn it from that path, I've failed. I failed to be able to understand all that terminology. And so at some point, I said, can I get some of the benefits here, but just kind of in a basic way?

[00:04:35] And that's where functional light programming comes from. So hopefully, that's another tool that you can add to your bag of tricks. And it should be something that you can compose into more sophisticated understandings as you continue your learning path. Are there any other questions that we can answer?

[00:04:53] Before we wrap up this workshop.
>> Kyle Simpson: Not a single one? Maybe it's that afternoon lull, all that good Thai food, okay. Well it's been an honor teaching you about functional light programming, I hope that you will experiment with some of these things. If you have any thoughts or feedback, again this is my contact info, I'd love for you to reach out for that.

[00:05:21] So we'll call it a rap. Thank you very much.