The full video and many others like it are all available as part of our Frontend Masters subscription.

Brian Lonsdorf

Brian Lonsdorf has taught several workshops and training courses on functional programming with javascript. He'a a regular speaker at conferences and helps organize/host FP events around the Bay Area.

Brian Lonsdorf

SFJS Co-Organizer

Joe Nelson outlines the scope of the course. The soul of functional programing is separating the concerns of what you are doing and recognizing those separations are happening. Creating clean code requires discipline. Custom names, looping patterns, glue code, etc. are side effects of a lack of discipline and invitations for messy code.

Get Unlimited Access Now

Joe Nelson: All right, welcome for real.
Joe Nelson: So all these people here is full of nice people online. I think it's really cool because what we're coming here to show you is a really fun technique of programming in general not just in JavaScript and only lately has it come to the JavaScript world.

But through the exercises we're going to do today and doing it in JavaScript is going to prepare you to do it in all kinds of languages like Haskel and Scala and Closure and all that kind of thing. And in fact, the title was hard core functional programming, so of course we took our stuff from House School.

The most hard core of all this stuff and we're going to use a style like that in our thing. So, in general I think if I were to like distill into like one message about the theme of everything we're doing is the soul of functional programming, and maybe programming in general, is separating the concerns of what you're doing and recognizing when those separations are happening.

We're used to just kind of being real programmers and just doing everything at once like you've got tests you're doing, and things you're writing and things are changing. And I think we need to separate what we're doing or if we separate what we're doing it becomes a lot easier to recognize patterns that happen again and again.

So you don't have to write them again and again. The way that your libraries can be built and the way they can compose gets a lot stronger. So I'm not going to be yapping the whole time. It's just how it's going to start and it's going to be like it's an exercise we are getting into and it's going to be fun.

So this is kind of the general structure of the course. I'm going to be teaching the silence. So this is the first bit and with the tools in the silence the silence is going to deal with the way we recognize and separate things. You're going to be writing code that's so pure and so good.

Brian is going to take you on The Voyage, which is where we take the code that you wrote in this new style. And you could take code that doesn't know things about the disk or the network or whatever, and just transport it in these little vessels to do whole new things in a whole new land.

And finally the demo. We're going to live code and just stumble over ourselves and it's going to be a lot of fun and make a real app using the stuff. So, let's begin at the beginning. In the beginning it was primordial soup that's the way I think of it, just anything goes.

If you look at this stuff, it's like printing and testing and go to and like yeah we get to do a thing because we're so good and we're so real and we're just proud of all the stuff we can do. So, I mean surprisingly when people were arguing you know this go to thing, it seems kind of wild west, it seems like can be confusing.

Like people like Dykes were saying that everyone's like now we can handle it you know. So you end up with a lot of names and changing like you know you're changing variables of things. You trying to track down to direct things in the right order. When did this happen?

And so like I said the slide advances. Some people were like go to is kind of a bad idea and in general we should be more disciplined in the code that we write. So exercising restraint can feel weird. So there's going to be things that we show you examples that you might be like, man this is kind of weird, like couldn't I just do this in like a line or whatever in some other way.

And when Brian takes you on the journey, then you could be like, look how nicely this fits in with my sailing ship. And once I'd like written it this way so I can go on the journey. So there's like, I was saying go to is kind of weird.

And nowadays we might look back to be like yeah, those were the Dark Ages, man. Like think of the stuff they were doing back then, go, I wouldn't do a go to. We know so much more but I feel in a way like we're still in the go to age we just have different things that bug us.

And when you're in the day to day. It's hard to like notice that yeah this is like something that can change, this is something we don't have to live with. And I think the way it manifests itself to me at least like these are some things some symptoms I feel I'm coding and it's like this is telling me yeah I should be separating what's going on.

So like custom names everywhere like having loops with weird names which will get into. Doing loops again and again, I mean probably this is like the pre recs of the course we're knowing something about map and reduce and filter and things. And if you know about those you're like yeah a lot of the loops I see are really just one of those.

But I just happen to put an index called I and I'm looping over stuff and it's kind of irrelevant. So looping patterns glue code which is like which we'll see. We're putting functions together and we like needing to come up with more names for the arguments of things like it just the way things glued together is very.

Even down to like in my opinion some MBC stuff where you have to make controllers that duplicate the names of things in your database is just a lot of glue and a lot of duplication. And finally side effects which are similar to go to I guess we have to remember what's going on and keep track of our stuff.

So talking about the names, this is just a word cloud I generated from some random Ruby library liaison object oriented lots of files, and these are just names from it. And what I've noticed is that the names that appear a lot happen because they're like do block which is like a ruby loop you know like each do.

Apparently it's going through like lines of files and repositories and stuff is modified because there's a lot of stuff changing. So like when I see these words themselves are suggesting to me like yeah this could be improved.

Ready to take your code to the next level?

Intense courses with world-class teachers and unlimited access to our growing library of videos for the great price of $39 per month.

Get Unlimited Access Now