Functional & Object Oriented Programming

[00:00:00]
>> This is not a functional programming [LAUGH] Course I promise. But we have started entering the deep dark forest of functional programming. So, yeah, as Samuel L Jackson would say in Jurassic Park, hold on your butt's. And this sort of brings us to the wider topic of programming paradigms in JavaScript, which I think bears mentioning as we are professional JavaScripters, because there's a lot of chaos going on here with different paradigms.

[00:00:39]
Being mixed. So what am I talking about? Programming paradigms. Well, some examples, there's a bajillion programming paradigms, but the most, some of the most common ones, and I think in the web development world, the ones that we're most likely to encounter are functional programming, or FP, and object-oriented programming, or Or if you were prefer, ooh, know what we'll call it.

[00:01:06]
Anyways, and they're, they're kind of instances if we will, mixing metaphors of what we could think of as like. Also as paradigms are often referred to as programming paradigms, but I kind of think of as like meta paradigms. Paradigms that encompass a whole way of imagining, ways of conceiving of programming.

[00:01:29]
So these paradigms, or meta-paradigms, essentially have a very different approach and a different focus on, like what we care about when we're writing a program. And in general, so functional programming Programming is sort of a implementation, if you will, of the declarative programming meta paradigm, which in general is focused on what you want to get.

[00:01:52]
What the result is that you would like to have from the computer. Computer, please give me this. As a As opposed to imperative programming, which is what OOP is sort of a subset of, usually. There's a lot more to say about that, but not in this course. [LAUGH] The how is more the answer.

[00:02:15]
So like an imperative command in English, like do this, do that. Set, log this to the console, set that time out, these kind of commands of first do A, then do B, then do a thing, and at some time later,do C, so on and so forth. This kind of very much order of how to do things, step by step.

[00:02:40]
Step is more the focus in that paradigm. And it's interesting because we see kind of, in JavaScript, we see both happen. Yeah. Well, we can have, for example, we're pretty used to talking about objects. In JavaScript. And we're gonna keep talking about objects a lot more in JavaScript.

[00:03:05]
And we're pretty used to writing these like, do this thing, and then do this other thing, and then do this third thing, kind of one at a time, like this, right? So we could define a variable, config, and that's essentially saying to JavaScript, hey. remember this value when I use the name config in the future and maybe it's an object that has some data what have you then I can maybe I have some program class or what have you I can define it in a new instance with the new keyword passing in The config that I just referenced.

[00:03:42]
And now that program is gonna probably remember that config for the whole rest of its existence. So we're mixing already a little closure in. But then maybe there's like a run method on that program. And I, in the run method, it's, we're setting it to a, just a very.

[00:04:00]
Exciting program that just tells you what paradigm it's programming in. [LAUGH] And so if we call program.run, we will get that out. Now we can accomplish the exact same thing in a functional way, but it looks quite different. So in functional programming Everything is functions. And we want to try to avoid this imperative do this, and then do that, and then do this other thing, for a few reasons.

[00:04:31]
But one of the reasons is how we can just swap out not with const, but with let. Let's say we can just swap out the values of things, and I don't know, there's all these asynchronous things that may or may not be running and whatever. And so in functional programming, we would tend to not sort of imperatively list out all the things we want JavaScript to do.

[00:04:53]
Remember this value, remember that value, remember this value. Instead, we're going to try to start from the what. Do we want? Well, we want a string, which we're using our little string template friend, that says, we're doing stuff in some paradigm. And that is gonna be, we want that to be the result of calling this run function with Some arguments, and we want that function, that thing that can run to be the output of a program creator that takes in, in this case, some configuration that has a.

[00:05:39]
Paradigm in it. And that's gonna kinda percolate through these functions and end up in what we see from the string. And so what we've got here is we are instead of saying, hey, JavaScript, remember this function as this name and remember this function as that name, we're naming these functions, which we don't have.

[00:05:59]
To in this syntax, but just for visibility. And so we're declaring a function saying this is what this function should do. It should turn a input argument of this object with the paradigm property into a function called run. And that function called run should turn some argument Into this a string that tells us what's happening and probably does a bunch of other stuff in the program.

[00:06:26]
And that function, that program, or that program function that we declare we want to kick it off immediately with declarative paradigm. And so you'll notice we have. A bunch of parens going in here. We've got parens around this function expression, and then parens like we're calling it with some value which is gonna be passed to paradigm which I'm destructuring here in the arguments.

[00:06:55]
And then a call of the value returned by that Because this is gonna evaluate to a function run. And then we can call that function to get our stringout. So this is gonna print out. Well, it's gonna say declaratively instead of imperatively. But essentially, it's gonna do the same thing as our object-oriented program.

[00:07:21]
Question, just a quick poll, a matter of taste. How many folks prefer this syntax. Seeing some shaking hands. How many folks prefer this? Okay, I'm seeing more hands. All right, in general, This seems to be a little bit more common, I would say. But we can also a mix and match with we don't have to be being so deliberate about being super functional programmers that can't use a variable ever we could, let's say declare these as functions and then call it just once and we would be functional ish programming