 Hello everyone. I'm Caho. It's happened more recently doing a lot of like the jazz work and of course tonight's topic, quick one actually, the title is called What's Functional Programming in JavaScript. So I think this only slide is only just for social, nothing, a lot of things I only in the one page note. Okay, actually functional programming, right, it derives from mathematics. So you see a kind of FX, right, looks quite similar when you do programming. It's like when you call function names and so on and so forth. And then it's like, it's just a function name. Then the round brackets inside all the arguments is similar quite like two math stuff, okay. But I just want to speak a bit about differences, what happened. So JavaScript wise, we have something like arrow functions. But well, you see, if you see after the arrow, right, if you use braces, I would say that's not functional programming. It's not, okay, but right, okay, from mathematical perspective, right, many, right, it's like about one line, just one statement, it's just probably like expression. So definitely you point braces, you definitely inside put a lot of statements, each statement is like do this, do that, do this, do that, and then after just a return. But in the functional part, right, okay, it just only like one statement is implicit return. So immediately after evaluating or like you come out of final value, automatically it returns. So usually, right, if there are of course a lot of like other tricks of how to do another thing, okay. I think it's not functional programming, it's you use something like maybe it looks like do wow, and then quite a lot of braces and fork, whatever. Okay, exceptions is definitely there's a function called for each. It's different from say for something in, the kind is like followed by use space, but in functional programming, if you use for, can use for each, and then inside, right, it's a function argument, you pass it in, because actually you see it like for each generally is like decorative. Okay, so what else is not really like functional programming is that, well, you use switch, if you use all the switch cases, again, sorry, that's not functional programming, let's say flow control. Well, I mean, the only way you're going to get out of here is that there's somehow like use question mark, send me an ambulance kind of ternary operators. Now, the last thing maybe, okay, this one thing that if they say you make the data which do processing or this and all data actually is immutable. So you don't really like change the stage when you like try to add, right, you come up with new value, actually consider like a new object somehow that, okay, it's also so then I would say like functional programming. So yes, on the last thing you mentioned about like not using switch and if, right, in a functional programming language, there's usually something called pattern matching, which allows you to like define different pattern matches and then effectively have what you would do in JavaScript with a switch statement. So how do you actually, like, so you're saying don't use switch statement or a statement, then what is your proposal turned to? Well, switch, I think, yes, a bit more imperative, but another trade is somehow there's kind of like mapping use of maps of somehow, but to make for this session because quite a bit quick, you'll be a deep deep into a bit of like functional programming, especially like those flow controls on. So I think I want to cover that beyond this session, actually, okay. So I mean, well, I already talked about error functions quite commonly used, but can be easily turned into something like imperative because you just like use braces or what, okay. So what actually there are like libraries here, I got two that was basically like mentioned one, actually the functional program version of the low dash, okay. So you npm install the low dash, but you when you import right just like low dash slash fp module, then you use the fp another is actually lambda. So these two of which I use low dash quite extensively rather than like lambda, but concept is almost there. I'm okay. So now come to a very quick question because here I may want to know more about demographics about how many people really like maybe curious about okay between like a functional programming and like those object oriented imperative. So you got two spectrums, one is very supportive is and the other end of spectrum is that you are really very oppressive about the paradigm. So question is for each of the paradigms functional and object oriented imperative, okay. Where do you actually stand in the two end spectrum? You can stand in the middle but it means something else. I find OOP super oppressive and every time you mention it, I kind of like get really sad. Okay, for each right, please try to explain or give your opinion. No separate, separate please. Yeah, because like, yeah, imperative programming and object oriented programming are different. Okay. So you want to treat imperative so not talk about object oriented because I think you can still use functional in object oriented. Okay, so it's functional against imperative. How do you want to collect these votes? Like, how's this going to work? Like, I mean, I've only got a hand up and down. I've got it's like a bull. Okay, okay. Each, I think randomly select each person and explain. Yes or no? Okay. We start from functional first. Who very supportive or not? Yeah. Yeah. How about the other end of spectrum imperative? Who? Okay, how about spin oppressive about functional programming? No, no, I'm not oppressive at all. A lot of people who advocate for functional programming are not necessarily pragmatic. I think a lot of the time when people are pushing for functional programming solutions, it's more about some kind of idealized purity rather than, Hey, I just need to get some stuff done if I want to throw in an if statement here. So what, you know, like, and I think this is one thing I personally like about JavaScript is the fact that it allows you to do kind of a mix of both when you have a task when you and you want to break out of the pure functional paradigm, you can do so for either practical purposes, you need to get stuff done fast or the computer needs to get stuff done fast. Sometimes functional programming isn't the fastest approach. Unfortunately. Well, actually, it's also down to the skills of how people really learn about functional programming. So actually, I mean, how many of you actually have really like no idea? It's like this is your first time to heard about functional programming. Any first time that you heard about functional programming? Does anyone use functional programming? I mean, just, no, just like a pool in general, you know? I know. I mean, first of all, I remember anyone used arrow functions with all the braces. Yes, because, well, if you use arrow functions with rounded brackets, I'm going to tell you that one is really another form of functional program. This is a friendly debate. You know, it's insightful. You have your opinion and we all disagree on different ways of using it. Like, I'm fine with curly braces. Yeah, I'm going to do something. Well, okay, okay. I think for one point is that functional, there are tricks actually, right? In terms that you can actually have like multiple, we call it multiple lines of statements. It's not like purely say that I want to have like just one single line, just that you make out a, yes, yes, JavaScript. It's just that maybe because it's just literal meaning, say that if you use braces, the chances are you're just like coding like to this, to that or some other. And then, okay, actually, you see from mathematical point of view also, right? Because this fx, your x is actually your input. They always return, they always have output. It's not like saying it's a white function. Although, I mean, truth to form, you can actually return nothing in functional programming. Like, say you return it, actually, inside it's really nothing. So, like examples before each function, then that's definitely you don't return anything at all. Generally, okay, when it comes to functional paradigm, okay, here's what I have a few points, but definitely what some other people say is one of which is talking about parallel and co-current programming, really. Because it's like we're just passing functions and arguments here. And then there's also like abstraction or data and abstraction or behavior, whereas impermeable may not be the same, we just try to abstract behavior. So, pattern matching, right? So, how do you propose an alternative to switch or if statements like control flow without pattern matching? Because you can't do that in JS. Before I forget about it, yes, there's one more thing that I think maybe you might need to consider is, I think performance. So, using the same code written using functional and using another paradigm, if you have a really long array to go through, like which one is actually faster, you might want to use one instead of the other. I saw some article about them comparing some JavaScript functions using filter and using the for loop. And then they found that the for loop was actually much faster. I need to go and find the article. I can't remember whether it's for loop or something, but it's yeah. Yes, but it's not the breaking thing, it was they went through the whole thing here. Any more opinions? Whatever is the fewest lines of code or whatever is easiest for other people to understand, and then I'll use whichever paradigm. I think the reason people talk about functional programming these days is because at the turn of the century we'd all been using imperative languages and everyone and not enough people were using functional. But I think in the JavaScript world we're seeing a lot of functional stuff, so we're quite lucky. And occasionally we have to pull the other one. Yeah, what you said just reminded me of the fact that let's not forget one of the main things that makes a language functional. That's not the only thing, but it's one of the most important things is that you can pass around a function as a first class like a primitive, right? It's not like I think like basic for example and many others. The function is like lexically where it is and it can never be passed somewhere else. And that's one of the great things like a lot of us are doing some aspects of functional programming without even thinking about it just by virtue of the fact that you can pass around a function. I have a question that may be dumb, but I don't mind. So assuming functional programming up to a degree of reasonable functional programming, trying to not mutate the code everywhere, any function should have a return statement in functional programming. Otherwise, if there's some stuff somewhere else that you are not controlling, just checking, making sure. Any function in functional programming does have a return statement? Yeah, actually it's an implicit return, it's not explicit. Yeah, yeah, but technically you say you can return the unit, which is actually nothing at all. Yeah, I think that's not the point of JavaScript. Starting to enforce stuff.