Hardcore Functional Programming in JavaScript

# Composition Exercise: Challenge 1 Solution

Check out a free preview of the full Hardcore Functional Programming in JavaScript course:
The "Composition Exercise: Challenge 1 Solution" Lesson is part of the full, Hardcore Functional Programming in JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

## Joe demonstrates the solution for the first challenge in this exercise. After that, he gives a few hints for the second challenge. Joe also engages in some audience discussions around scalability and maintainability of functional programming code. - Problem: http://jsbin.com/jevag - Solution: http://jsbin.com/gowugugaso

Get Unlimited Access Now

Transcript from the "Composition Exercise: Challenge 1 Solution" Lesson

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

[00:00:04]
>> Speaker 1: All right, here's how number one works out. So our challenge is to return a list of author names in articles using get, compose, and map, okay. So if we look back up, where do the authors live, they live-
>> Speaker 2: All right everybody, we are going to go over the solution to number one and setup number two.

[00:00:32]
>> Speaker 1: Here we go, number one, get it right then we'll have more knowledge for number two. So we want to pluck out, I guess I could say it that way, the author names, cool. So we have an array, what's in the array? Objects, we want to get the author, yes, but their name in particular.

[00:00:55] So when I hear something it says, get me a list of blah that you've kind of pulled out of some other blah, it calls to mind map. So the outermost thing is probably like I want to map over some stuff. So, what is it that I want to do?

[00:01:14] How do I wanna transform each thing in the array? Well, one thing I could do is like get the author themselves out. So I could say get, or actually I may not get, maybe the same, get author. This is not quite there, but let's see what that does.

[00:01:37]
>> Speaker 1: RAM does not define is what it does.
>> Speaker 2: [LAUGH] Keep it running a few times.
>> Speaker 1: Try it again.
>> Speaker 2: Just fix itself.
>> Speaker 1: It does?
>> Speaker 2: Yeah.
>> Speaker 1: It must be JS bin like loads and runs these things.
>> Speaker 2: Yeah, and each time you change-
>> Speaker 1: Yeah.

[00:01:50]
>> Speaker 2: Maybe that's what's happening.
>> Speaker 1: That's not good. Okay, anyway, so here we go. Uncut, so here's the deal. He wants to find, no, that's different, yeah, yeah, yeah. These names equal object, object, object. Okay, we're almost there. You know, like we just mapped, instead of getting the right thing, we got too much.

[00:02:11] We got the whole author, and we just want the author's name. Well, let's go back down. Here it is, so I'm gonna put this on another line, so we can kinda see it. We're mapping get author. It's true, but we have like a process of things to do, and when you do one thing and feed it into the next thing that's a composition.

[00:02:34] Or we could think of it as a composition. You could do all kinds of ways, but it's pretty clean this way.
>> Speaker 3: Actually, one thing that helped me was to run that over in the console. Put that map just so that you see the output. Because that's the hardest thing to sometimes just imagine what it's doing.

[00:02:50]
>> Speaker 1: Good idea.
>> Speaker 2: And if you have names. Name should be available right there on the right too
>> Speaker 3: And then you can can apply it to articles
>> Speaker 1: Right. And that helped me a lot.
>> Speaker 1: See, right, right, good call. Yeah, code speaks better than I do, I like it.

[00:03:15] [LAUGH] Here's what that would do. If all we're doing is mapping get author, we get a new array back, because the original thing was an array. And it has the authors, So what would if we were considering each author in isolation, what would we be doing to that?

[00:03:32] Now one thing we could do is map a map. It's kind of inefficient though, you have to go all the way through, get down to the author, now wait a second. Yeah I guess, but another thing you could do is compose what you're getting out of the things.

[00:03:47] So we've got an author, cool. And remember compose is right to left, so the first thing it does is get the author, and we're gonna feed that into getting the name of the author, because at this point we have their.
>> Speaker 3: I did the map of the map.

[00:04:05]
>> Speaker 1: That's one way I think there's like this. When you see the patterns, map versus map with compose is called loop fusions. So when you like zoom out, it's like, yeah. You can alway, and without hesitation, when you're working with pure functions, convert one into the other and get an efficiency savings.

[00:04:21]
>> Speaker 3: Okay.
>> Speaker 1: It's like, yeah, when things are like very nailed down, I know what they do, and I have laws that they obey, you can just transform your program and make it faster or simpler.
>> Speaker 2: And we'll talk about that in functors too.
>> Speaker 1: Yeah.
>> Speaker 3: Okay.

[00:04:36]
>> Speaker 1: Hopefully it runs. There you go.
>> Speaker 2: Yeah, cool.
>> Speaker 1: Didn't have an error. Whats wrong?
>> Speaker 2: You guys can tweet about like how exciting it is to get a different error and like nobody would know that unless they were a dev. You're like, yeah.
>> Speaker 1: It's so true.

[00:04:55] Okay so that's challenging.
>> Speaker 3: That we just assume that it's progress?
>> Speaker 1: Yeah.
>> Speaker 2: Yeah. [LAUGH] Unless the system is broken.
>> Speaker 1: Yeah.
>> Speaker 2: Yeah.
>> Speaker 3: Statistic had a chapter that a successful test is one which fails.
>> Speaker 1: Yeah.
>> Speaker 2: Something different.
>> Speaker 1: So I wonder whether we just spend like five minutes on two and then we just give the solution to two?

[00:05:19]
>> Speaker 2: Yeah, part one ends right after. Coming up to the end of this, right?
>> Speaker 1: Yeah, I think we are coming up to the end of it.
>> Speaker 2: Yeah, so we're good. Because our demo is going to be a lot less than two hours. So, we're going a half hour over than what we scheduled, then we're good.

[00:05:32]
>> Speaker 1: Cool.
>> Speaker 3: Is there a hint you can give on two?
>> Speaker 1: Let's see, two.
>> Speaker 3: Because Mark and I are stuck.
>> Speaker 1: [LAUGH] Let's see. Make a boolean function that says whether a given person wrote any of the articles.
>> Speaker 2: I can give a hint. You gonna need a function wrapper around this one.

[00:05:52]
>> Speaker 1: [LAUGH] I'm not sure if that means the same. You need a closure?
>> Speaker 2: Well, you're gonna, it's not gonna be just map and compose. You're gonna need a function. That because of the way it composes it needs some random arguments. It is actually a really good demonstration of that.

[00:06:09] So you're going to need to write a function, colon, parentheses, return, all that junk around this one.
>> Speaker 2: Scott S and Michael H mentioned they've got some combinatory or combinators and RAM though that you could use instead of four, which is kind of cool to know?
>> Speaker 1: Yeah, challenge three was just for the fun of it to be like how point free, quote unquote, can you be?

[00:06:37] The idea that you can strip arguments away and not name them. Sometimes it should be like it's counterproductive. Sometimes it's really nice.
>> Speaker 2: Scott posted a cruel tidbit.
>> Speaker 1: Show that, we should probably show that later, after the solution. Yeah I see.
>> Speaker 2: I don't know, you can get yourself into some serious problems if you're like, must be point three.

[00:07:05] Point three is just a really good way to like know you're on track writing declarative code. You're not making, you're pretty much on the right functional track if you're writing compose a lot. But don't like force yourself to write everything where you're, did we even mention what point three was?

[00:07:20]
>> Speaker 1: Only just now obliquely.
>> Speaker 2: Point three is you don't mention arguments at all. You just glue functions and data together without ever receiving arguments.
>> Speaker 1: Like a man or a cow or other. That is out of the picture. We have to get the error you take the error out.

[00:07:38]
>> Speaker 2: Yeah so, you can write all these point three and you get a lot of benefits. Because, you're just combining things generically without ever needing data. And you don't get tied into names that make your program very specific. It's also really good indicator that you're on the right track of functional programming, and you're being declarative.

[00:08:03] You're forced to be declarative if you're writing point three code. Which is, you're just saying, here's a high order, do this. Don't say how to do it, just do it.
>> Speaker 3: So, I get that this gives us a lot of terseness and maybe code sexiness. It gives you terseness, but what about maintainability and scalability across teams with different levels of competence?

[00:08:28]
>> Speaker 2: So one thing that you gonna gain is you're working at such a, if you go up to maybe the top example of just that composer, the author, and the name. But so compose, map, split, that doesn't say how to do anything. It's saying this function is the composition of these two arguments and those just like in like SQL or something.

[00:08:50] Somebody can make map way more efficient, compose way more efficient, split more efficient, they could do all sorts of stuff. You haven't said how to do anything. You just said what needs to happen. We're going to compose these two things. And so length has a perfect definition of, almost reading to what it's supposed to do.

[00:09:09] It says we'll split it on space and map the size, and that's the composition of these things. So you're gonna have a much more maintainable code base, because you're forced into a very high level of coding. That gives you a lot of wiggle room in implementation. But with the highest level of programming, you're gonna have to fire the people who can't understand the approach [LAUGH].

[00:09:35]
>> Speaker 1: So basically, more or less everyone.
>> Speaker 2: Yeah.
>> Speaker 1: There's different levels of obscurity though, if you're just using like compose and map and stuff. It can read kinda nicely just like you're looking on Unix. Do this, pipe into this, pipe into this, just down the line. There's a presentation, maybe the ramda creator can post.

[00:09:55] There was a great talk showing, like do you want your code to look like this, and it was crazy. Or he like put it through bunch of compositions. It was really clean. So I think it can look better and clearer. But like some of it's straining, like at the bottom like use fork and when yeah that's kind of weird.

[00:10:09] It's just, there was just as an exercise and like thinking about moving variables maybe not in the way that you want all the time on that one.
>> Speaker 2: Can I back up and say shouldn't find people like this? [LAUGH] I think there's a lot of value to low level code and a lot of value to different types of programming.

[00:10:28] This is just a way of programming in a declarative fashion, so if you need that flexibility underneath you can get it.
>> Speaker 2: Okay, challenge two. Make a, okay.
>> Speaker 3: So, what you're saying is we write the linked function and let the low level guys use it.
>> Speaker 2: Exactly, just like, hey, we write codes to make this way cooler or make this math more efficient.

[00:10:54] And your application code just reads like a DSL almost and the implementation code is, as long as your application is at high level, everything could change