This course has been updated! We now recommend you take the Functional-Light JavaScript, v3 course.
Transcript from the "Exercise 1 Solution Part 2" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Kyle: Saw a couple hands, yeah?
>> Speaker 2: Wouldn't you have 175?
>> Kyle: Sorry, I typed it wrong, the question was wouldn't I have 175? I just completely mistyped. Yes, the end result would be 175. Was that your question as well?
>> Speaker 3: Yeah, I just wanted to make sure that I got the right answer.
[00:00:20]
>> Kyle: I have not had enough coffee apparently I can't do my math this morning, okay? I said 175 and typed 125.
>> Kyle: Yes?
>> Speaker 4: There was a question, is it possible for an app to have all of their functions pured?
>> Kyle: Well, we could quibble about that. I would say in general, the takeaway would be If your program was entirely pure with no side effects, that would mean your program would have no input our output.
[00:00:48] And if no input or output, then your program would be completely pointless. If it had no effect on anything, there was no observation of it, there was no state change as a result of your program, then I know what you can do with that program. You can simply delete it, because that's about how useful it is.
[00:01:05] That's the glib way of saying you're going to have to balance where you need purity and where you don't. And you notice, again, I didn't start this workshop to say functional program, function, do all functional, do all functional. Functional's cool, but it's not the hammer that you use for everything.
[00:01:23] The perspective that we're taking here is there's some usefulness to it, and there are places in our program that will make it easier to reason about. So I don't encourage you to write your entire program in a functional style, I've never once done that. But I have used some of these functional concepts in my regular programs, and the places I've done it's improved the understandibility, the reasonability back out.
[00:01:44] Good question online, thank you.
>> Kyle: Okay, I see a question in the chat room. Where would you use all these pure functions if you're using frameworks like angular and such? My answer to this is not going to be terribly satisfying, but I'm not going to answer any questions about frameworks.
[00:02:04] Because that's way outside of the scope of what we want to talk about here. I'm not an angular expert, there's plenty of people, who are very smart about angular. And I would recommend, if you're doing angular programming embrace the angular way. Okay, because angular has a way of doing it.
[00:02:18] If you're doing react, embrace the react way. My goal is to really sit at a lower level than frameworks and to talk about the mechanisms of the language itself and how we can use this mechanisms. So, I think that's entirely possible that you might be able to improve some of your angular code with some functional live programming concepts, but the chances are you are not going to be able to do a full functional programming pass and still use angular because that's just not the mindset that they used to design that framework.
[00:02:47] The same would be true for react, and ember, and backbone and all of that. That's one of the reasons why I am teaching this workshop, by the way. As I am trying to make some this stuff more palatable, even in mixed environments where you know you're not going to be able to go entirely functional programming, these are little tiny tools that we can use in very tactical specific ways.
[00:03:06] Yes?
>> Speaker 4: We're kind of getting a few here, so.
>> Kyle: Okay, great.
>> Speaker 4: Bear with me. Is it best to return an array? What else could we return? What are the way could return Y and Z keep the functions up here, sorry.
>> Kyle: You're going to have to wrap it in some container, the two fundamental containers that we have in JavaScript are going to be the array and the object.
[00:03:27] So we could have gone to the trouble of assigning several different values and the properties and the object. Usually, functional programmers like array. They like lists because lists are very convenient to do operations on. So, my instinct in a functional programming mindset or anything that's even remotely close to functional programming, my instinct is to reach for the array before I reach for the object.
[00:03:51] But, any kind of container would do. I mean, even a more sophisticated container like a map or a set or something if you wanted to. You're going to have to have some container because syntactically, the language only allows you to return as single value, if you need to return multiple values.
[00:04:03] Another way of answering that I guess is to say refactor your program so you don't have to return multiple values. But that may not be something that you use as general advice. So when you do have to have multiple side effects, you're going to need some container with the return keyboard.
[00:04:20]
>> Speaker 4: Can you repeat what a pure function is?
>> Kyle: Yes. A pure function is a function that has no side effects. It operates entirely on its own variables, its own state, or any of the things that are passed into it. So the arguments that are passed in, and any of its own- it operates entirely on that.
[00:04:39] And does not change anything. A pure function does not mean it doesn't access outside state, it means it doesn't change the outside state. So there's no side effects. So I could write a function that accesses a variable outside of itself, and that's totally okay. And that's not going to be considered, at least from our perspective for our intents and purposes.
[00:05:00] That's not going to be considered an impure function, except for the fact that that variable now can change from out underneath this function, so the overall reasonability of the program is less pure. But the function itself we still call pure because it's not, it does not have a side effect.
[00:05:17] So if you take precautions to make sure that you do not do side effects in a particular piece of your program, then that piece of your program is pure.
>> Speaker 5: If I run this program, I get z is undefined or something.
>> Kyle: Well, here we're not, so the question was Z is undefined.
[00:05:35] The way I rewrote this, I'm not using Z anymore externally. Remember, z is only being used internally. That was part of the point. Z was a set of state that we didn't want to change on the outside, so we encapsulated it as a local variable inside of bar.
[00:05:48] We do use it for the brief period of time between when we declare and while foo is running, it's changing, and then we return it, so we do have it there. But it's not exposed on the outside, that's intentional.
>> Speaker 4: This might have been, I don't know if this is out of order, but they were asking why do we return z if it's not being passed in and changed?
[00:06:17] But I don't think we are any more, right?
>> Kyle: Okay, so that's actually a very good question. We are returning z, we're not passing z in. Z is not an input, z is an output. Z is how I observe the output of this particular program. If I didn't give you z, it wouldn't be a terribly useful program, would it?
[00:06:39] So this is, again, we're not going to get way deep in the weens of functional programming, but this is one of the ways you can think about, as a functional programmer, even doing side effects without side effects, is to simply pass in everything that's needed and return everything back that's needed to be observed.
[00:06:56] Passing the inputs, receive the outputs. So here, one of the direct outputs is the Z variable, and one of the side outputs, one of the state that we may or may not choose to track and use later, is that Y variable. So I'm returning both of those, and that's why I need some container around me.
[00:07:18]
>> Kyle: We good? All right, excellent. Those are fantastic questions, thanks very much for that. That's exactly the kind of thing that we want to pay our attention to.