 Hello, folks. I was speaking to you from the rather small but very cosy fourth bedroom of my house at the moment by reason of all the rubbish that's going on in the world. So, talking about functional programming in JavaScript. My contact details are there on the screen at the moment. Feel free to grab them if anyone's interested. I'll try and put this back up at the end. I'm around on social media and available if anyone has any further questions slash abuse to her like me. So, I'll move on. A little bit about me. I've been doing software development for about 15 years now. Started off working for a little mobile application development company here in my hometown where I had to do stuff like develop a mapping system for buses, which was great because I had to test it by going for a walk around the local park repeatedly. I absolutely had to. It was the only way to do it. Then moved on to Capgemini where I worked on a system that made sure that everyone in the UK pay as their taxes and of course I've never had any abuse for that. The works, there was a big bookshop firm in the UK, proto labs, they're a manufacturing company for the US and Eurofins are now recently, I have become one of those contractors that your mum always warned you about. So, I'm working for all sorts of people at the moment. I'm a big fan of films, so I don't so much have a schedule as a programme of events. We are going with the slightly inaccurately named 6Ws who, what, where, when, why and how of functional programming. So, first off, who is it? I'm going to introduce three people significant to the history of functional programming. One of these guys is a software developer. See if you can guess which as we go around. But this first gentleman is Alonzo Church. He, I don't know if anyone can see my, can focus in my mouse pointer. I'll take your silence as a yes. Okay, wonderful. Sorry, didn't know how interactive we are. This is the first of these I've done. So, this gentleman is significant for a few reasons. Amongst them for us as developers is this guy, the arrow function. That's what this is. It's an arrow function. This is mathematics, though. This is from an old mass paper from the 50s. And the second is this guy here. This donate to parameter. It's the Greek letter lambda. And this is where we get the term lambda expression. This is Haskell Curry, who has something like three programming languages named after him. And we're interested in him for this, which I'll be getting to later. This is currying. Don't worry about what that means at the moment. Now this guy might well be our software developer. I can't imagine why we think that. This is John McCarthy. He developed arguably the first pro functional programming language in the whole world. Lisp in the 1960s. So what is functional program not the point of the last few years. The point of the last few slides was to point out that it's not new. There's nothing new about functional programming. In fact, I started digging into the math papers that formed the foundation of functional programming and they date back to the late 1800s. Honestly, I can't understand a single thing written in any of them because I'm not a mathematician. I'm an engineer. I don't understand it, frankly, but it isn't new at all. It's not like the latest version of angular reactor, whatever. It's not the latest framework that's competing with the others. It's old. It's been around for a long time. The first programming language dates back to the 60s and most of the heavy work dates back actually to the 50s. It's not actually a language. It's a paradigm. A paradigm is a style of programming in a way. If we want the metaphor of a guitar, then we may take our guitar and we may play many forms of music on it. We can play rock. We can play pop. We can play country if you have no soul, whatever. But the point is that you can take your language and do many things. So similarly with our programming language, we can do procedural. We can do object orientated. We can do functional and an awful lot of languages these days support all three. JavaScript particularly supports functional very well. And what is it also not? It is not imperative nor is it object orientated. Most of the folks that I found that struggle with understanding are the folks that have been doing object orientated for 10 plus years and find it hard to adopt to a slightly new style of work. It's not the solution to all of our problems, although I would argue it's the solution to many as hopefully I will demonstrate over the coming 40 minutes or so. It's also not difficult. I'd argue it's really not. It means dropping some preconceptions and learning a slightly new way of looking at a dev, but it's not necessarily difficult. So what actually is it? There's a whole load of concepts. A lot of these have got rather strange, complicated names, although what they actually mean generally isn't all that hard to grasp. Immutability. This just means that once you've set a variable, you can't change its state. In the JavaScript world, pretty much just means stick const on nearly everything and stop using that. All far higher order functions. This is something that folks in the JavaScript community have been doing for ages compared to folks over in like dot net and Java. This is passing around functions as if they were variables, either as parameters to a function as the return from a function. However, but that's all it is function as functions passed around as variables. It emphasizes functions, not statements. Now, what does that mean? A statement is something like an if it's aware it's for anything of that sort. Speaking as a rule of thumb and functional programming, if there is a question, the answer is usually functions, more functions. And that holds surprisingly true for a lot of situations. Referential transparency. This means that a function does not rely on anything beyond its parameters. And the consequence of this is that it becomes extremely predictable in its behavior. This means that given the same parameters, it will always return the same answer, no matter what, no matter the life of the universe, no matter the state of the system. Let's just switch it off. No matter anything. So this makes it very, very, very testable, very predictable recursion. I'm hoping we're all good on recursion. If we're not going to dwell on recursion much in this talk, but you know, yeah, it's an important pattern recognition will come to that. So this is kind of like a case statement with knobs on stateless. There's no state object orientated tends to rely on the paradigm of you've got your state object, you update it, and you keep touching the same state object. We don't generally do that in the functional world. There are reasons amongst them. And one of the great benefits it brings you is that things like async become very easy to support because you don't have a shared state between functions. There are other ways. Now the monads. Monads is the one that has a reputation for being an awful pain in the bum to understand. And certainly if you go looking on Wikipedia and some of the slightly more math sea sites, you will see these really horrid definitions of monad that involve f of G is G of whatever I don't really know. I don't understand. I'm not a mathematician. But according to Douglas Crockford, the curse of the monad is that once you gain the ability to explain it. Once it once you gain the ability to understand the monad, you lose the ability to explain it. So not really necessarily planning to. And it is not difficult, as I'm hoping I'll demonstrate over the over this talk. So where is it? Where do we find it? There are of course the pure functional languages. Never use them personally. I know some folks that swear by Haskell. I think it has got its uses all over. I believe there are some queuing systems out there that are written in airline rabbit MQ. I think that's an airline. The functional programming with each iteration of dot net that gets released. And it's working out pretty well. And they've even got a mostly functional language F sharp, which is an alternative to C sharp BB, whatever. And of course, JavaScript. JavaScript definitely does support functional very well. When is it? So when is it particularly good? It's good for data processing that is given this data turn it into this data. That's the sort of thing functional does really well. That's very pure. That's not requiring much interaction concurrent systems. That is where you want to stack a whole load of instances of the same function side by side. There's no shared state. So concurrency is very enabled by functional. High criticality because functional programs in general tend to be more robust than object orientated or procedural code. So if it's very important that your system go up and stay up, then functional might well be something to consider. Allegedly with stuff like airline. Once you've actually got it for to compile, then nothing on this earth will ever make it break. Now, I don't know. I've not tried that, but it seems entirely plausible. And serverless, if we're interested in serverless, mostly for the previous three reasons, that's, again, functional is the sort of thing that might easily enable you to get into serverless. So where is it not? Now, it's not that functional can't do these things. It's just that these are some of the areas where you have to make compromises. You are obviously because there is nothing more impure than a human being. They they're about we're about as dirty and impure as it gets to the computer world. Now, obviously JavaScript off is obviously often meant to be out on the front line with the user, but what we need to do generally is maximize the pure area of functionality and then minimize the amount of dirty human interaction. External interactions with other systems, same sort of reason input input, interactive with files because who knows that the file is there is not there, whatever this is all and high performance. Okay. I don't know why that. Oh yes, high performance systems because sometimes it depends. This might not be the case with JavaScript so much with some systems with some program language certainly like C sharp. Making it more functional may not necessarily be functionally the most performant choice. But this may not be the only concern you have when developing your system. Often we're more interested in testability in sustainability readability. If you're more interested in those things, which in fairness I would argue that most businesses are because most businesses are keen that the development efforts get done fast. Rather than anything else then again functional is still probably what you want. So why is it why, why are we interested. It's concise. You can now normally I would gesture wildly with my arms but you have to imagine that at the moment, but not you can compress pages of code down to just a couple of lines, potentially it's a lot more concise than old fashioned object orientated procedural code. It's more readable, mostly because of the decision that you've added in with compacting the code right down. And it tends to enforce the writing the code in an order of operations that's more logical and consistent with what we're actually trying to or trying to achieve a testable mention that and concurrency have mentioned that and robustness. Hey, and it's fun. I hope everyone will agree by the end. So this is an old fashioned bit of object orientated procedural code. Now, if I gave everyone five seconds to understand what on earth this was doing you'd probably struggle. And there's a good and that's because our order of operations is all over the place. There's all sorts of bits of code structure in there that are just there to be structure. It's it's a bit harder to read than say something. Oh, sorry. I'll go on to that in a moment. Sorry, slides for all to change that. Okay. But in functional we can just write this on about a line or so. So this is my test case. This is what I'm actually feeding into the thing. This is a test I what I'm actually doing is I'm taking a small little CSV of the titles of Doctor Who stories for those unfamiliar Doctor Who is the greatest TV series in the entire world. And this is the story titles from the first series in 1963, along with my personal rating of those stories. So what I actually want to get out of it is pass this down to data structure and then take out my favorite stories and then give us back the titles, which is what this lot is actually doing in a slightly convoluted way. And this is how we do it functionally. If anyone's thinking this is just an awful lot of out of the box. Yes, six functions then. Yeah, pretty much. That's what it is. And if you've been developing in this style, you've pretty much been doing functional programming for a while now. And what how we doing again at the order of operations is nice and simple and laid out in a flow split on new line, then split each of those lines on comma, do a filter where I'm parsing item two to it and then checking it to before, and then finally select out just item one easy. That's an awful lot more compact than the first code sample. It's a lot easier to read and understand what it's done. It's a lot easier to modify because we can easily just throw an extra line into this functional flow. It's obvious where to make a change in how and that's what functional programming is what we want to do in effect is put the rest of our language into this structure in order to continue. And I'll demonstrate using some of one of my favorite libraries I'll introduce at the moment and I did say that I would get into it the concept of currying. So, in a normal non-curried function, we let's say an ad we taken into that should be a bar. I may possibly have reused these slides from another language. We've got a bar A, a bar B, and we're just saying it goes to A plus B. So that's easy. Give it a 10 and 20, we get a 30. If this were a hypothetical curried ad and we gave it only the 10, does anybody out there want to hazard a guess as to what we get out as the value of answer two? Well, the answer in fact is that you get back a function because as often in JavaScript in functional programming, the answer is a function or functions. So if you give this curried ad simply one parameter, the 10, you get back a function which kind of demonstrating here, which has the one firm value filled in and the second still required. And that is a parameter to the function that's been returned. So by giving our ad a single parameter, we've converted it into an ad 10 function. And this seems a bit strange, but it is in fact very, very powerful. And then you can just give it the second one. You can call this answer two function, give it the second parameter and you get back an answer finally. So the way to that we can introduce this to JavaScript is by one of my very favorite libraries in the whole world. This is Ramda JS. I'm a huge fan of this guy. And most of the rest of the talk is going to be using Ramda, which I'm a big fan of this provides an awful lot of functions that are very similar to things that like underscore or low dash give you. But given a more a more distinctly functional and approach and using currying on everything by default. So this is an example of a Ramda function. This is one filling in all the parameters and here. So Ramda uses it and what you call a namespace are generally. I mean, when you're importing it, you can call it what you like, of course, but our is as good as anything. So our nth says, give me this array and I will give you the whatever is in the nth position. Nice and simple. So all it means is in the one position, whatever you're you're getting that item so zero one, it's that one. So we're saying one is the position data is the data. It gives back a capital B because that is of what that's there. So far, so good. But what we can do is we can only give it the one. We haven't given it the data at this point. So what that means is that get array one here is now a function. It's a function that given any array fed into it, it will give you whatever is in position one in that array. So now I've defined two arrays data one and data two. And I'm forming an array here down here, which is a quarter get array one here with data one fed in and the data two. So I'm reusing the exact same code to fetch the first item out of each. So we ended with an array at the end, which is a B and an F a B from this one and F this one. And I've defined in one position what the logic is for turning my array into the data that I want. And this is a ridiculously simple example. We wouldn't necessarily do this in the real world, but it's just to demonstrate the principle. And you could just easily slide it into my existing functional chain here, our nth one here, because everything in Ramda, unless you supply every single parameter to the thing, evaluates generally to another function. So this is my arrow function simplified without the arrow into a simple call to nth one. And what I'd like to do is to try and pop the rest of this structure into the same use the same approach to compact it down and hopefully simplify further what we're actually trying to do. But first, I need to introduce another structure that I'll be using. So I used to work for a US company. And being British, one of the things we would often do is discuss the weather, because this is no joke what British people do a lot. So the American folks would say and I'm not doing the accent because I can't and it's embarrassing, but they would say something like it's 100 degrees outside. Now, I would think 100 degrees. Ooh, that's hot enough to boil water. What the hell. But of course they mean 100 Fahrenheit. The system used as far as I'm aware, only within the US. So the formula for converting from Fahrenheit to Celsius is deduct 32 multiplied by five divided by nine. Because of course it is. Why wouldn't it be. But what we have is a series of operations here and each one is taking a value operating on it, storing that somewhere. And then the next line is taking the previous step, modifying it further and so on step to step to step like a relay race. Now, because of that, we've got an awful lot of code noise here. We've got all these consts that actually we're never going to use aside from just in this one instance this a is unused here is beyond here. We've got the return and so on here and strictly speaking all of this we don't really need. We could use a perfectly nice structure in Rambler, which I will be getting to. But first, Rambler does have an add subtract multiply divide it has all of these guys. So we can start throwing these into functional trees as well. These, of course, are all carried. So if we simply wanted to add or multiply, then it's very easy to create a quick curried version of those. If we do the add and call our pass only attend to it, then we add 10 easy peasy. We've got to add 10 function similarly with the multiply because the order of operations doesn't matter with these guys. But with the subtract and the divide, the order of operations is important. When I say subtract 2015 here, this is 20 minus 15. It's actually in the order that you would sort of say it when you're describing describing a mathematical operation to divide somebody is there 100 divided by five. So if we want to carry these guys, we probably want to actually change the order of operations or to carry a function other than. Let's provide other than the second one as our parameter to our resulting curried function. So Rambler has a feature here called R dot. It's an underscore underscore. That's actually two underscores. This is a function that is a special case. What it's meaning is with a subtract, I am supplying all of the parameters. I'm saying that the one that the curried function that comes out of it should actually supplies its parameter is the one I'm saying. I'm saying this is the whole. This is the bit that needs to be filled in by the next call to the function we're generating. So by doing this, I'm saying, please now get next person supply the first one. And then I'll give you the 15. So that in a fact means I've now created a, oh, that's wrong. That's wrong. I've now created a subtract 15 function. And down here again, I am telling the thing that this is the one that I want to be supplied later. So I've done just created a divide by five function. Easy. So then finally, we can put all of this stuff into my new Fahrenheit to Celsius converter using something called pipe. And pipe does exactly the process that you saw on the old version of this code. It's now bearing in mind, of course, as again, with almost everything around it, this is a function. So our pipe is a function that takes a single parameter, which is whatever it is that's been supplied in, which hopefully is a number. She probably want to actually do some validation of that in the real world, but I'm keeping things a little simple here. So our pipe takes a single parameter, which will be our 100 degrees. And then it passes it to the first function in the chain, which is a subtract. And we're filling in the blank here. So it's taking whatever that parameter passed in is filling it in there subtracting 32. Whatever the result of that is pipe will now push it into this one to multiply by five, whatever the result of that is will push into here. And then we'll fill that final value here and divide it by nine. This in its very simplest form is a monad in case anyone was interested. There's more to a monad than this, but this is the very simplest version of that, that concept, a relay race, just a series of operations, each one passing a value to the next after operating on it until finally we collapse out to a final value at the end. And returning to our our function here, this is our parser. So if we wanted to convert all of this into a rounded up structure, we can now use our pipe. Yep, there we go like that. So pipe says give me the value, then I will do our dot split. And again, all of these are carried functions. These all generally take one more parameter than you're seeing here. And that final parameter is almost always the value the data on which to operate. So I am splitting on new line, then I'm doing a map and our map is just the same as a map as we're used to it. And into that I'm passing the function our dot split. So split on new line split each line of that on comma, then a filter, which is filling it in long hand there. I'm actually creating an arrow to function to do that. There's probably a smarter way, but that's that looks good enough to me. And finally, our dot map where I'm passing it our dot and which is that means go through the entire array and select out the first item from it. And functionally, this is exactly identical to all the previous versions of the parser you've seen. You can run this through unit tests, you'll get the precise same result. But this is a bit more compact. And we're relying a lot more on code that someone else has provided for us. So moving on to another sort of example of the sort of functional structures we would do. This is a password validator. It's a password validator with a series of rules, but it's quite long. It's got a lot of repeated structure with these early return falses. And we could compact this down a whole load make this a bit easier to follow because I've seen how out of hand these things can get if you let them. I've seen functions of this sort that end up growing so much that they end up looking like family trees. And the functional structure will tend to restrict people in terms of how much of that sort of craziness they try. So we've got our rules. It must not be undefined and then convert to a string. And then we're saying it must be less than or equal to two. It must be greater than 10. It must not be just in Beaver because it must not. So that first bit is easy. That last bit, sorry, is easy. A function in Ramda to determine whether something equals just in Beaver is easy. That's just R dot equals. So this again is a carried function. So whatever you pass into is evil now it will evaluate it against this and to tell me whether or not it's it's the same. This is what we've actually generated behind the scenes. But if we want to find out if it is not that if we want to. If we want to reverse the logic of that function, then our compliment is what we would use. So our compliment takes a function that returns Boolean and then it returns you back a another function, but one which does the opposite of that. So this R dot equals checks whether we are equal to just in Beaver. But a compliment of that checks that we are not equal. So it is not X is triple equal to just in Beaver. Easy. And if we wanted to assert against properties, well, that's not too difficult either. This proper EEC does exactly that. It says that this gets back a function which asserts that the property B is equal to capital B. So if we were to feed this function, this object, we'd get back a true because it does have a B and a B. So that's fine. But the property that we want to assert against is length. And we don't want to say that it's equal to something. We want to say that it's within a range. Now there is actually another function for doing this in Ramda and that's prop satisfies. What prop satisfies requires is wouldn't you know it a function, which is the function. That's the predicate that we're saying has to be met in order for this prop satisfies to return true. So we're saying that whatever this property is, it has to be greater than two. Here we're saying that the property we're asserting against is length. So this now has returned a function which will check the length of any given object you pass to it and assert that its length is greater than two. And we can go a step further and just use R dot GT greater than and pass it to two. And we've got back exactly the same thing. So this then is the new version of my password rules. So I'm using a structure here called R dot all. Now all would be certainly very familiar to me from my C sharp days. And what all means is I am going to give a whole list of functions and I'm going to evaluate them one after the other. And given that any of them return false, then I will terminate the soul thing early and return out false. And in this case, what we're doing is this again is a single parameter function. This whole thing validate password is a function which takes a single parameter, which is our data, which will be hopefully our password. One second. Sorry. So and it's passing that same value one after the other into each of these functions I have generated. So the first is actually an R dot is nil. And this is our catch or check against whether the value, the variable is defined or not. And I'm doing the R dot complement of it. So this effectively means first check that this thing is undefined or whatever. And this thing means do the inverse. So what I'm saying is that I'm actually saying that all of these things have to be true in order to be validated. So this is in effect, it's not nil. It's not undefined. It's not whatever R dot is is so flipping useful that I would use it all over the place. And this is passing the type as it were that you wish to check it to be. And it'll tell you whether that's true or not. So I'm saying R dot is string. So we've passed in our password. We're checking that it's not undefined. Now we're checking that it's a string. So the rest of the predicates can continue safely on the assumption that this is a string. Because otherwise, once we start checking against length, it could be an array or who knows what. So prop satisfied, I'm saying greater than two and prop satisfied less than or equal to 10. So that's our lengths satisfied. And also that it is not just in Beaver because it must not be. So all of that gives us our set of password rules. But again, written in a fairly nice, fairly easy to read way. It's very easy to understand how exactly to modify. If if I were ever to throw in a new rule, it would literally just be an extra one line in this structure or maybe a modification. And it's, I would argue it's a lot easier to work with. I mean, there is a little bit of the overhead of this R dot business. But once you pass that, the rest of it's quite easy to work with. So another example requiring us to do some slightly different work. And this is something that probably an awful lot of us in the programming biz will be familiar with. And that's fizzbuzz. For those unfamiliar and I'm not thinking there's going to be many of you. This is a very simple game where we write out numbers. If one of them is divisible by three, we add fizz. If it's divisible by five, we add buzz. If it's divisible by both, like 15, we add fizzbuzz. I don't know why, but this, this is the go to coding exercise. I often get set in interviews, but fine. So how would we do this using our functional Ramda code? Well, first off, we'll need a map, of course. And we'll get on to exactly what the implementation of this cat. This is the thing that says given a number. Here's the output that I'm going to give you either a number or a string. I'll get into that in a second. But first we're generating a range. Now the range is saying generate me an array between length, which has values in it between one and whatever num is, whatever the, whatever the highest number that you want in my previous example, it's 20. So this is generating us an array of integers between one and 20. And then using map, we're feeding each and every one of those into this function here. So another structure to introduce, that's the if else. We'll be using that in just a moment. And this is handy little kind of like logical switch statement. And this again is a function and takes a single parameter like everything else. And it's saying first off, whatever the parameter is, pass it into the first item in the structure. That's in my case, it's R equals five. So what it's saying is whatever has been passed into this function here, pass it here. And this will tell me whether or not it equals five. If it does equal five, then pass it into this function and do the transformation. Now always means that's what it always returns. So always means disregard the parameter and just return this. So if it is five, we get back F I V E five as a string. Otherwise pass the parameter into this one identity. Now identity actually also means disregard the parameter. Well, no, it doesn't. What it means is take the parameter and just return it completely unmodified. So my little F L structure here is saying take a parameter, check whether it's five. If it's five, return back the text of five. Otherwise, if it was three, let's say, then return that back that three exactly as it was without touching it. So moving on, we've got we've got a pipe here and the pipe is using the if else. So this is a pipe. So it's passing the parameter. This is the thing that's called by the map in our previous line of code. So that means that this is operating on each item in this range array between one and 20. So the parameter to these is an integer between one and 20. It's operating on each one individually, one after the other. And it's checking them against these rules. It's saying first, is it divisible by three? I'll get onto that in a moment. And if it is do our duck concatenate, I'm putting the whole here to say my original item goes here and then we append fizz. Otherwise, if it is not divisible by three, then our identity, that means return the original value back unmodified. Similarly here, if it's divisible by five, then we concatenate buzz. So that's a pipe. And we are either concatenating a fizz or a buzz, or if neither of those divisibles were true, then we're simply returning identity and unmodified value. So that's all of our logic for doing our fizz buzz pretty much in that one statement. The is divisible by, by the way, looks a bit like this. And that's a pipe where we passed it. Math mod is our modulus of behaving in a mathematical way, which apparently the percentage in JavaScript doesn't always. We're saying pop the value there. Num is three or five as appropriate. And then we're saying return back whatever this was passed into equals compared here to zero. So there we go. That's a divisible by one of the last of my examples. So this is a card game that was introduced to me as pontoon. But apparently in the US, it's known as blackjack. I've also heard it called 21 and a few other names. But the basic idea is that you're taking cards one after the other from the dealer. If it's a number card, it's equal to that number. If it's a jack or a queen or a king, the value of that is 10. The ace actually is equal to either one or 11. I've simplified a little because I don't want to get bogged down too much. So I'm saying the ace is 11. And the idea is that you're taking cards to get as close to 21 as you can. But if you go over 21, then you've lost. It amused me as a kid. And if you wanted to do old-school, you'd do something like this. If statements, stuff all over the place. But all we're doing is the scoring at the moment. Our dot is because frankly, it's too useful not to. So there is an our dot contains because I don't want to do big long strings of ifs, looking at queen, looking at king, so on. When the answer is all the same, I just want to do one. I want to compact that out a bit further. The problem with our dot contains is it works in a slightly interesting way for what I'm used to. And that is that first you say the thing that should be contained in the array, then you pass the array, which is the other way around to what I kind of was kind of like. I would like the array and then I would like to pass in the thing to check it contains. So all of that just means that we need to use another r dot underscore underscore to fill in the, to tell it to fill in the blank here. But this is using another functional structure called which round is called conned, conned for condition. And each parameter to this, this whole thing is an array and each item in the array is itself an array, a two-part array. The left-hand side of each of these is a predicate. That is something that takes the parameter, evaluates it and then returns a true or a false. This true or a false is does this rule apply? So r dot is a number means if whatever the parameter is is a number, then simply return it unmodified. Moving on to the next line. We've got a slightly more complicated condition and that's a contains and I'm saying our blank is here. So we're filling in here and I'm saying look in this array, if our value is contained within this array, return 10. So it's an r dot always 10. Otherwise, if it's an ace and r dot always for 11. So this structure, this is pattern recognition. This is what it is where it's kind of like a switch statement, but with full-on functional expressions on the left-hand side rather than simply checking against value. And then on the right-hand side again, we've got a full-on function of some kind. This sort of structure is extremely powerful and can enable you to write an awful lot of code that would otherwise be complicated and long-winded. So if you want to imagine the sort of basic functional flow, we start with an item that's called a string. Generally speaking, the first option chance you get, you split it into an array of strings or string or whatever. Maybe you do a where or something or a filter rather to reduce the number, a select or a map rather to convert to something else. Finally, aggregate into a single value again. That's the sort of standard flow that we'll run through when we're doing a functional process. But this aggregation is the last step in the process that I haven't really touched on so far. There are some built-in simple aggregators. Some will do exactly what you think. Passage of an array, you get back the sum. Mean takes you an average. Easy. But we want to do something slightly more complicated. We want to take an array of cards in our hand. So in my imaginary example, I've got a 1, a 5 and a K. So that's 1, a 5 and a King. King's worth 10. So that's 16. And I want to convert all of this into a single value of the score. And that's where R.reduce comes in. So R.reduce takes a function with two parameters, the accumulator and the value. So the accumulator is the running total so far. And the value is the current item out of the array. It also needs to pass it the starting value, which when we're calculating our scoring cards is going to be zero. So when we run this the first time, the accumulator will be zero because that's here. The value will be the first item out of our array, which is a 1. And so we're saying that the new running total is accumulator. That is the old running total. Add the score of the card, which is over here. That's this function that we created, this pattern recognition structure. So 1 will go into scorecard. It'll actually match. There is a number come back as identity. So the new running total is 1. So then we'll call this function again. And the new accumulator is 1. The new value is now 5. And we're saying that that is equal to the old value. That is 1 plus the score. Now again, it will be 5. So that means that the new accumulator is 6. Calling this again. We've got 6 here and we've got K here. So when that goes into our scorecard, this will not match. So we won't do identity. This one will though, and it will match on King. So that means we'll bring back a 10. So finally, we'll get back our 16. Took me an awful long time to explain that, but didn't take me very long to write it. And once you're used to working with this pattern, it's not really all that difficult to throw these together. And if we want to go another step further, more complicated, we could do a pipe, which is first, which then first does our reduce, reducing our array down from this list of cards to a value. And then do an if else to say, if it's less than or equal to 21, we'll do identity. So that's your actual score. Otherwise, we'll do an always with bust. So in my imaginary example, if we pass in the 1, the 5 and the King, we'll again back a 16. Otherwise, if we have a queen in there too, now the queen will take 16 to 26. And that means that we will switch to being bust. Again, awful long time to explain, not much time to read or to understand. So this is the last bit. And then you can all relax. So I've got a hypothetical DB get of some description. I don't really know what it's doing. I don't really care. And it's getting a record based on an ID. And inside this is a data object of some kind. I'm imagining it's user data or something of that sort. And I want to say hello to whomever details I've just fetched, possibly the devil. And I will call first name on that and put it into a string. Now that's fine provided that this actually works, that we actually do have a record coming out of this. And this is not just undefined because otherwise this is going to explode. So there is a structure in functional programming that will allow us to do this sort of thing without having to sort in an awful lot of checks against undefined all over the place, muddying up the code and getting in the way of understanding what's going on. This is one way of implementing it. I've seen it done all sorts of other ways. But typically it's called maybe. And maybe is an object that just contains a value. Think of it as a thing in a box. So we've got our value. We're popping it inside the box. Maybe is the name of the box. And we've got two functions hanging off its prototype. The first is to get value, which is just take the thing out of the box and hand it over. And the second is bind. And bind takes a function. And what we do is we check whether this value is actually defined or not. If it's not defined, we will not execute the function. We'll just return another maybe with undefined contained within it. Otherwise, we'll return a new maybe. At this time, we will execute funk whatever this is with the value from inside our box popped into that. And that's what it would actually look like when you run it. So I'm saying my message is a new maybe and I'm starting with my ID. And I'm using bind and passing it in a DB get record. So X here is the 666 and that's going into there and that's executing. Now, if this worked, this means that this first bind would return a new maybe with whatever the result of that is popped into it. And then the new maybe would have a bind on it. And this would be the result of that. And then we could safely operate knowing that this is defined. It might not be a terrible idea to possibly put a try catch around it again just in case first name doesn't really exist. And then finally you call that value at the end to get the value out of it. But if on the other hand, this return nothing, then this type of this value would be true that would be undefined. And we're simply going to return a new maybe. So that means if DB get record return nothing, this bind will not run this function here. This function will never be run. But an undefined will be returned. So the value at the end will be undefined. And we can do something like at r.cond or whatever to decide what to do with it. But the point is that I've written my flow of operations in this single chain. And I don't need to start adding in lots of code to check against whether the previous operation worked or not. I can add in as many extra lines as I like. And all of these can assume that the previous step succeeded because otherwise the step will not be executed. And this is what a monad really is. This is the sort of thing that we really do with them. There's a whole load of other monads covering all sorts of other other eventualities. You could have monads which return different objects depending on whether previous steps worked or not. You could have monads that switch to containing error messages on the result that an error occurred. In fact, if you've been messing with promises, those are a monad as well. So you may have been using some of these longer than you expected. So I've got about 10 minutes left, which is not bad timing at all. Does anybody have any questions at this point? Thanks a lot Simon. I am in charge of the questionnaire site. There are questions for you. Yeah, it's not scary. How many of them contain abuse? None of them contain abuse. All of those have been filtered away already. The first question is, for someone who knows programming C and Java, what do you think would be the best functional programming language? Any books you can recommend? Well, okay. I haven't done C since I was at university. That's longer ago than I really care to admit. Java though, again, I don't know Java, but I do know C-Sharp. So C-Sharp is actually a really good one at the moment for getting into functional programming. Because as I said right at the beginning, Microsoft now have a policy of introducing more functional abilities to their language as they go along. Things like the pattern recognition. It's not entirely as powerful as the structure I showed you there, but it's getting there. And I believe it's something they're continuing to work on. So I would actually recommend a book called, I think it's Functional Programming in C-Sharp by Enrico Buinano. It's published by Manning. And it's honestly one of the best programming books I've read in a very long time. I absolutely adored that book. And it's examples of how you can start doing functional programming in C-Sharp today using no extra libraries. And it explains things like the MONAD and the pattern recognition system so nicely that it's easy to work with. And the best thing you can do is don't just read it, grab out Visio Studio or whatever and do it. Because a lot of the difficulty in understanding functional programming often comes from the concepts and getting your head around it. And if you sit there and do it, I almost guarantee that after some time there'll be a light bulb moment and suddenly it'll all become just obvious. And certainly for me now, I get a little annoyed if I have to write everything out longhand, as it were. Doing it the old way rather than doing it the nice, quick, easy functional way. So that's my personal favorite book. There is functional programming in JavaScript by the same publishers. I haven't read that in a great deal of detail. It looked quite good, but it wasn't entirely what I was after personally. It uses underscore. So if you're familiar with underscore, you might find that one useful. But personally, Ramda is one of my all-time favorite libraries for almost any programming language ever. Also, I'd recommend checking out the Ramda website. They have extensive documentation on how their library works. Nice. We'll make sure that we'll get the links for the books and we can publish them together with the slides later on. Okay. Oh, I haven't got my camera on. So that you nice people. Hello. You're currently not visible, though. They can only see the questions. I can put you on screen. Oh, yeah. There are two more questions, though. I'm already married. I'm sorry. What do you think of observablehq.com if you've heard of it? I have not. I am really sorry and I'm literally writing down that right now because I'm so sorry, but I've never heard of it. All right. One last question, which goes more on the board, I guess. What do you think about Rust? Again, not heard of that one. Apologies to everybody. That's a programming language, I think, isn't it? So I do not like that in my car. I don't know anything about it as a programming language. So again, apologies. JavaScript and C sharp are predominantly all I ever work in. All right. That's all the questions we had. Thanks a lot for the talk for me as a Haskell evangelist ever since I first saw it. It's great to see that functional programming is catching on everywhere nowadays. In fact, I was having a chat with the summer interns. When I was in the U.S., I was having a chat with their summer interns and they were saying that in their universities now, functional is the sort of programming that they're teaching them. So I do get the fit. And certainly when I go to things like NDC Oslo and things like that, I get the impression there is more functional content each year compared to the previous. And people are starting to name check at least functional even in the non-functional talk. So it is definitely a very coming thing and something that's becoming extremely, increasingly important as the years go on. Yeah, it's nice. And thanks again for a great talk. And with that, I would like to thank our speakers, our sponsors and all our viewers.