Hardcore Functional Programming in JavaScript Introduction

Transcript from the "Introduction" Lesson

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

[00:00:39]
>> Joe Nelson: All right, welcome for real.
>> [LAUGH]
>> Joe Nelson: So all these people here is full of nice people online. I think it's really cool cuz 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.

[00:00:55] But through the exercises we're gonna do today and doing it in JavaScript is gonna 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.

[00:01:12] 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.

[00:01:34] 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.

[00:01:51] 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 gonna be yapping the whole time. It's just how it's gonna start and it's gonna be like it's an exercise we are getting into and it's gonna be fun.

[00:02:04] So this is kind of the general structure of the course. I'm gonna 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 gonna be writing code that's so pure and so good.

[00:02:21] Brian is gonna 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.

[00:02:38] And finally the demo. We're going to live code and just stumble over ourselves and it's gonna 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.

[00:02:55] 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.

[00:03:12] 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?

[00:03:25] 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 gonna 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.

[00:03:48] 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.

[00:04:01] 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.

[00:04:14] 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.

[00:04:31] 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.

[00:04:48] 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.

[00:05:05] 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.

[00:05:22] 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.

[00:05:41] 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.