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 "Exercise 4" Lesson is part of the full, Functional-Lite JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

In this multi-part exercise, you will combine a number of the concepts learned throughout this course. Before starting the exercise, Kyle shares a few observations about the process of learning functional programming.

Get Unlimited Access Now

Transcript from the "Exercise 4" Lesson

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Kyle Simpson: Hopefully some of those ideas of functional programing light, functional light programming have been stirring around in your head. Closures and recursions and immutable value usage and things like that. We're gonna finish up our workshop with an exercise, Exercise 4, it's basically the last thing we'll do with this workshop.

[00:00:25] And the goal here is to sort of walk through some steps that make you practice that, and to borrow the term, to compose those ideas together a bit. It's still silly problem solving, we would be here all day if I tried to give you a real program and tried to in context do that.

[00:00:46] So they're still silly, simple academic like examples, but hopefully they're a little more concrete, and we can start to figure out how these things fit together. So, [COUGH] we're gonna start with this empty EX4.js, and rather than this be an exercise that I just turn you loose on for the next 30 minutes, and have you do yourself, we're gonna kinda make this a little bit interactive.

[00:01:08] I'm gonna say some stuff, and I'll stop for a minute and let you type, and then I'll say some more stuff, that kinda thing. So this'll be an interactive thing, roughly, probably 30 to 40 minutes-ish of us discussing, and we'll figure out when we've gotten all of the usefulness out of the exercise and then we'll wrap up.

[00:01:27] So, the first thing that we're gonna start with, and if you follow along with the readme, that's fine. If you want to jump ahead, you may miss a few of the points that we're making, so I would encourage you maybe not to do too much of the jumping ahead in the readme, even if you feel like you're ready to go onto the next step.

[00:01:44] But you can follow along with the readme cuz that's basically what I'm gonna do. So, what we're gonna start out with, and one other thing, to kinda give you a heads up on, this is another one of those things that in functional programming, I've observed from the outside.

[00:02:00] I'm coming at this all from the reverse angle. I didn't start out learning functional programming. Douglas Crockford has a great quote on this topic. I don't know if it's original him, but he has a great quote on the topic. That the problem with functional programming is as soon as you understand it, you stop being able to teach it.

[00:02:16] And there's humor there, but there's also some truth there because as soon as you really understand and you get steeped in all the academic tradition and the terminology, it's really hard to switch back. So rather than go that direction and be ineffective at teaching, my goal is to come at it from the backend, from the reverse.

[00:02:36] So I don't know whether, I'm not gonna get certified as a functional programmer anytime soon, but hopefully some of these things are starting to fit in a little more concretely for you. But one of the things that I have observed from that backend perspective, coming at it from the reverse, is that there are some times when an abstraction gets created, and you look at the abstraction and you think, what even remotely prompted somebody to come up with that?

[00:03:05] And the best metaphor I can give you for it is, if you remember back, maybe in high school or whatever when you took an algebra class and, or maybe it was a calculus class or something like that. But you've been working along with some problem and you're trying to solve for x in one side of the thing, and it's not clear how you're gonna, you get to some point and the teacher's working through the problem with you, and it's not clear looking at it, that there's an easy way to isolate the x, to solve for x or whatever.

[00:03:32] And then all of a sudden, she's like, well, if we multiply by y cubed on both sides, and you're like, what? But she does it, and all of a sudden, it just magically makes everything, it unsticks the logjam and then you can move on, and that used to drive me insane.

[00:03:50] How did you just pull this rabbit out of thin air that just magically worked? What was it that did that? And I don't have a terribly great answer for it, but it is to say this. I think functional programming, my perspective, one of the most important techniques that you can get or one of the most important skills that you can get at functional programming, is developing instincts for things.

[00:04:12] And that's basically what my algebra teacher said was, I've done it enough that when I see a problem that kinda looks like this, I just remember that I can invoke this pattern and it helps to unstick the solution. So really, functional programming is kinda like that, sometimes you invoke things out of thin air that don't logically flow directly from what you just did, but they unstick you.

[00:04:34] They create an abstraction that unsticks you and makes a solution to a problem work. So there are gonna be a couple of these things where I'm gonna pull something out of thin air and you're gonna be like, why are you passing that function in that way? It's really more based upon those instincts.

[00:04:47] That's really what I'm trying to get across with this whole workshop is to help you understand what those basic principles are in functional programming, and let you try to weave those together into instincts. When you look at a problem, I want you to have the instinct to say, I've seen that before, that's a transform.

[00:05:03] I know how to do that, I can pull out map. Or even if it doesn't look yet like a transform, but you're trying to figure out the cleanest and most straightforward way of expressing a solution to the problem, maybe something will go off in your head and you'll say, I have an instinct that this is probably something I could do with map.

[00:05:19] I can wrap this value in an array and do it with a map and that will make more sense. So it's those instincts. It's those pulling solutions out of thin air thing that seems to be how functional programmers are so good at what they do. That's just an observation that I'll make, and we will see a little bit of that as we go through.