 Okay, welcome back to the technology room everybody We've been some interesting presentations so far, but we're running a little bit behind so we're going to get racing straight into the next one We've got Cameron Ball from Moodle HQ and he's going to give us a a rundown on the wide-eyed crazy functional programming Which covers a bit of philosophy and the age of parallel computing So any questions put in the forum if we can't get to them now we will get to them But for now it's over to you Cameron Yeah, good day. I'm Cameron from Moodle HQ. I work on the Moodle Cloud team and I'm here presenting What I think maybe the first talk at a Moodle Mood that's actually not about Moodle at all I mean, it's tangentially related. It's about programming I originally wrote this as a personal project and I presented it internally at Moodle HQ and it was so well received that Everyone was like hey, do you want to do it at the Mood? So yeah, why not? Here I am So let's get into it Right. So this first slide is intended to get your brain sort of bit activated. We got a bunch of fun little Facts and anecdotes here Let's go through a couple of them won't go through all of them It was intended to be so like a lobby while people join the chat and There's a good one all the back to the future happened in the past Maybe we'll just go through two or three of these to get the the brain fully fully engaged the cortex fully engorged and Everything is in the future. It's a very profound quote Now we'll go for one more that is a good one functional programming and procedural programming are owed to these two Pre-socratic philosophies. I encourage you to look those guys up because they're pretty cool All right So let's get into it. This is the talk called wide-eyed crazy functional programming And yeah, there's me Cameron middle-cloud developer and of course some fun animations because you cannot spell functional without Fun and I need this slide here just to let the confetti settle because otherwise the next slide chugs even more And so when I first presented this a few people curious about the title and I imagine a bunch of people out there are curious About the title. So I thought I'd come up with a slide to clarify what it means I'm gonna take it. There we go. So this is this is figure 1.1. What most people consider a typical Functional programming advocate bit of an eccentric crazy and they spell these nonsense words like monads applicative funk doors lambda calculus every few seconds and often they don't have very much hair and Of course before we get too far into it. I want to I want to add a bit of framing to the talk My goal here is actually not to teach you functional programming What I want to do is get you curious. I want to get you longing for more and You know every good talk has an obligatory quote and he is mine I think it really helps convey the framework I used when writing this lecture If you wish to build a ship do not divide the men into teams and send them to the forest to cut wood Instead teach them to long for the vast and endless sea. So that's my that's my goal here I want to get you to vast for the long and endless sea of not dysfunctional programming But I'm programming in general. There's there's lots out there to learn and you know Some people don't even bother learning about the other stuff there. So Yeah, and we can't forget attribution because that way everyone knows how cultured you are and how many important things you've read in your life And I actually don't know who said that. I'm not cultured. I'm Australian Really, sorry And with this framing in mind, I'd like to encourage you not to take any of the code examples in here too Seriously, there's not many They're mostly to demonstrate big picture ideas So what is this talk about I'm gonna commit a cardinal sin of teaching and I'm gonna tell you things It's not about It's not about Haskell and it's not about convincing you to stop using whichever language you like And it's not about mathematics When when trying to explain things there's lots of perspectives you can try slice that from and for this this talk I've gone for a very meta perspective Which is perspective itself As I said, it's not a talk about Haskell. It's about viewing programming through different perspectives And it's broken up into three sections. I think I think it's three sections I'm gonna pause for a bit at each section and when I do that, I'll encourage people to write questions in the forum I'm not gonna answer questions at the end of the talk because like I said, we're short for time And it's just better if I can go to the forums and answer them there So yeah, let's let's get into it What is functional programming? There we go profound it is programming with functions Really everything is a function Which does beg the question Come on change the slide. What is a function now? You know, I assume a bunch of you are watching our programmers and they've heard of functions before But functions in the functional programming context are a bit different What a function is is a mapping between two sets that associate every element of the first set to exactly one element of the second set This is different to functions in procedural languages and the the name function is a bit of a misnomer in that context I think they should have been called Procedures or subroutines and that's actually why those languages are part of the procedural programming paradigm a Function a true function is a mapping you can think of it similar to an array in PHP like you know if you have an array in PHP it associates the keys to values So say you have a key and no Jeff and it points to the string. Hello You can have another key Maybe chef that points to the string. Hello. That's fine, but you can't have Jeff point to two values and a pure function is exactly like that and in the same way a PHP array can't do anything except express a mapping a pure function can't do anything express a mapping you can't mutate state And as I just mentioned those are what's called pure functions And there's a good chance that I'll just say functions for the rest of the talk because I forget And this has some very interesting consequences in a functional in a purely functional programming language We have no equivalent constructs for for loops while loops go-tos variables and probably a bunch of other things There's little asterisk on the variables there because you can actually have variables, but it's in the Mathematical sense you can say like x equals 3 and that means they are one in the same You should be able to substitute x for 3 anywhere in the program And you can't change it unlike in a procedural language where you can reassign the value whenever you wish Now this this begs the question Who in their right mind would want to do that? So I'm here trying to convince you functional programming is awesome because it has less features That is true. It does, but it actually doesn't make any difference You can accomplish anything in a functional programming language that you can in a procedural language And yet why the best answer I can give to that question is learning is good And this is where it ties into Moodle. We're all about education. So we should be all on board with learning new things And it's brain plasticity idea Learning learning functional programming for someone who you know spent a lot of time doing procedural style programming It's gonna cause you to it's gonna require you to Wrestle your brain into shapes that it's never taken before which is a really good skill to develop it's gonna leave you with this plasticity to learn a great of a variety of things to encounter in life and It's also gonna make the maths cortex of the brain Very very buff. I said there's no math in this talk and there's not but if you do decide to go on a Functional programming pilgrimage you will get a buff maths brain And it helps with communicating as well functions. Sorry programs written in the functional style are actually easier To communicate to people Then programs written in the procedural style, but of course that relies on the other person speaking the same language as you Right. So this is the section on paradigms I Was gonna pause here for questions, but I don't think anything I've said so far as particularly Controversial maybe it is but I'm gonna soldier on here just for the interest of time So in particular, I want to talk about the two most widely used programming paradigms And they are the two that are the most adults with each other actually So we have the declarative paradigm and the imperative paradigm and inside those we see sub paradigms And there are ones that sit outside of those like for example SQL is declarative language, but it is not functional and assembly is a Imperative Language, but it's not procedural. You can't you kind of procedures if you write assembly Although the vast majority of imperative languages are indeed procedural and then inside the inner boxes We see some examples of languages that are written with that paradigm in mind So for the purpose of the talk, it's probably okay to just think of declarative and functional It's interchangeable and imperative and procedural is interchangeable and there's a very good chance I'll mess that up as I go through the talk. So what's the purpose of this diagram? We're gonna do our first up of that perspective change Some people might have realized that those are both words used to describe human languages and that's relevant Because learning a new paradigm is beneficial in the same way learning a new human languages And so I've rewritten this as if I was a linguist and What those words actually mean so declarative a sentence which expresses a statement of fact something like he runs I like climbing ice is cold Taylor Swift is gonna go on a date with me one day I messaged her on my space a few years ago Just waiting for her to get back Taylor if you're watching my emails at the end of the video and then in imperative We have a sentence which expresses instructions or requests, you know, shut the door. Don't eat my burger Let's go to the pub. Don't hit on Taylor Swift and I Imagine you can see the similarities with with Imperative programming there like it's a clear set of instructions to follow And he is just if you remember nothing else This is this is how you remember them declarative is this is this imperative is do this And when you think about Programming as I explained with the functional paradigm. We lose our instructions word instruction words We lose the for while go to variable reassignment all that stuff and That brings us to one of the first big brain moments in the talk which is programming languages are human languages We do not write programs for computers. We write them for other people to read and So, okay Why is this declarative thing good because surely in both cases the human language case and the programming case? We learn something useful We we learn the ability to instruct people to do things like surely that's useful How do you do anything if you can't instruct people or computers? Here is one thing that we gain in the imperative style we gain Sorry, the declarative style we gain a temporality and that is Something being independent of or unaffected by time So a declarative program expresses what it actually does it expresses things in terms of relationships In an imperative paradigm thinking about the program means thinking about changes over time So think about your loops you got your variables in your loops and you've got to keep track of what's going on over time in your head But in a declarative paradigm you just think about relationships You look at something at what something is and how it relates to the other things around it And then you move on with your life and it's a bit of a weird idea But it does actually end up giving you more brain space to focus on solving the actual problem You're not tracking all these things going on all over the shop So why again? There's some reasons you can read them I'll say that some problems are simply very difficult to solve in the imperative way and That's especially true when you're talking about events that might be happening in parallel And may run at different speeds on different executions of the program Something that comes to mind is JavaScript if you ever use JavaScript in the days before promises You would have run into huge amounts of pain making requests to get data or something and you've got you know Variables to try and track which one finished first and this sort of thing you just you get yourself in a mess Really really quick and you can come up against data races just by virtue of the way the program is expressed And there's a little quote there that I really like constraints liberate liberties constraint. That's a fun one to think about and Yeah, at this point. I mentioned a lot of you people are thinking Enough of the philosophy and linguistics mumbo jumbo. Let's let's see something interesting. So here's a Code example. This is no particular programming language. It's one that I just came up with although it does look like Many languages. They're out there And this is a really interesting example because these two snippets of code behave differently depending on which paradigm you interpret them with So in the declarative paradigm this code the X equals X plus one will hang and not complete execution Whereas in the imperative paradigm it runs and And This code will run in the declarative paradigm, but it will hang in the imperative one and We'll explore that a bit more in the next slide So here we are we're gonna just interpret it using English So in the declarative paradigm we say X is the same as itself plus one which it doesn't make sense That's no good. It does does not compute, right? Whereas in the imperative paradigm because it's a set of instructions We say evaluate the thing on the right of the equal sign Then store it in the thing on the left of the equal sign and that's a list of instructions that can be followed and it makes perfect sense This one in the declarative style We read that as the repeat of X is X Appended to the repeat of X which if you think it through that's just an infinite list of X's Of whatever X happens to be in the imperative paradigm We evaluate that as we interpret that as to evaluate the repeat of X Just build wrong First evaluate the repeat of X. So there's obviously a recursion problem there We can it's defined in terms of itself and the instructions can never be followed because they just cascade out forever and Again, I'll just reiterate this programming languages are human languages the parallels. They're really really cool Imperative tells you what to do declarative tells you what things are and Here's some actual code that you can run if you have Haskell installed or something like that. This is Haskell syntax The double plus is the concatenation operator and this is the exact same as the definition I showed before and You read this as Three F's is the first three elements in an infinite list of F's and that's completely fine If you have an infinite list of F's of course, you can just take the first three. It's no problem It's a shame that the function name is take because that feels a bit like an instruction word, but you know, whatever no one's perfect by contrast in the JavaScript version we interpret this as first compute an infinite list of F's and Can't do that right, so That's pretty cool. I think because we can express what things are we can express an infinite list in in a declarative language And none of the declarative Stuff relies on tracking changes anywhere We just need to know what the thing is and how it relates to other things and we move on with our life And we've gained the ability to wield infinity, which is pretty cool That's something that you have to worry about a lot when programming things cascading out of control But now it's not a problem anymore Right, so this is the next section about promises. I'm gonna I'm doing pretty good for time So I'm gonna pause for two minutes if anyone wants to write questions in the forum Well, what I just spoke about is fresh in your mind. Please do so and after the talk I'll go through and I'll answer those while we wait I'll just go back to this guy and we can we can look at some of these little little quotes Yeah, if you can be disgruntled, can you also be gruntled? That's a good one There's more stars in our galaxy than there are atoms in the universe that one blew my mind when I first realized it and Point nine recurring is exactly equal to one a lot of people dislike that but it's true That's a really fun one about English spelling if you look at other words where those letters appear You can see that it produces the word fish And one of the facts is a complete fabrication and it would be very unfortunate if it was this one This is interesting. Yeah, if you sift through pie your credit card details are somewhere there And I'm pretty sure that's actually how scammers get credit card information They just sift through pie looking for valid credit card details. That's how I do it anyway And one seven two nine is the best number. I checked every number and that is the best one I'll probably wait for another 30 seconds and then move on. It's very strange not getting feedback during a talk I don't really know if people are ready to to proceed or or what And I see I actually ate a banana before doing this talk just to get a bit bit more strength buff brain We're back at the start of these. So, okay, I'm gonna continue back where we left off. We're in the section Oh, wait, hang on. No, we're not we're in the section about promises JavaScript promises That seems like a bit of an odd tangent. Why am I talking about JavaScript promises? But let's go with it and I'm gonna break the the cardinal rule of teaching again by telling you what promises are not Promises do not make things asynchronous There's a lot of misleading information out there that seems to indicate that they do You can have perfectly synchronous promises But the thing the thing you pass as a callback till promises not get like run in the background or anything like that So just wanted to get that out the way And this is this is what promises really are They solve these these problems they solve asynchronous request management error handling for computations which may fail and Probably a bunch more stuff that I forgot and so what are they a promise is a value which may or may not be available yet That's where the asynchronous part comes in that value might come in later wrapped in some additional context and Some functions to instantiate the wrapper in this case we've got promise resolve and promise dot reject and A rule for composing the wrapped values, which is the then method Now to have a quick JavaScript recap because I'm going to be using this notation That one at the top the X with the arrow is equivalent to that function definition And what is composition? It's a method for combining two things of the same type into another thing that is also of the same type And just a quick note on that. I'm sure a lot of you've come across function composition There's many different kinds of composition But function composition is very common, especially in programming However, in this example, we're talking about composition of promises in the sense that we combine two promises and get another promise Right. So promise composition The then method of a promise except the function is an argument and this function takes a value and returns a new promise The new promise combines the previous two using the composition rule that you pass into then So I hope it's not too small In this snippet above there are three promises So there's the first one We got just promise dot resolve some value and this is a completely synchronous promise because the values there immediately And then here this thing itself is a promise. It's the composition of the first one and then it uses the composition rule X plus And another value to produce a new promise using the value from the previous one And then the third promise is the composition of all three. So this Function here is using this composition rule with the promise that was composed back here So you end up with a promise with the value some value and another value and another one And this here still results in a promise. It's a slightly different. We have a reject in here And the way that works is any subsequent call to then just leaves you with the rejected promise So we just end up with a failed promise with the value. It's all gone wrong So this is what I mean when I was talking about Computations that may fail. It gives you a nice elegant way to handle that like, you know, maybe the request times Or something like that Right. So, yeah, why did I show that who cares? What we're doing there is we're declaring how we want the promises to compose and we've come up with a system where the order That the promise has actually resolved their values in is no longer important And in other words, the timing aspect is gone and we can declare failures anywhere in the chain So those words are sure starting to sound familiar And this is one of my favorite things. This is uh JavaScript code and this is Haskell code and they look so similar So if I hover over this you can see the the symbols that correlate Um in Haskell we have this thing It's called it's called either it's called either type and instead of promise.resolve They have right and instead of promise.reject they have left but this example using just rights So promise.resolve we start here. That's the same Then this funny little arrow guy here. That's the same as then And this is just the Haskell way of making like an inline function promise.resolve And then we're doing string incatenation there and I mean just they look so similar you'd think one copied the other But it's not true. They it's an independent Thing that emerged in both languages Um And here's the the failure case. We've just chucked a left in there So in the top one we get a failed promise with onos and in the Haskell one we get a left with onos Um, so if you've ever used javascript promises You've been doing declarative style programming all along without even realizing it And yeah, we get some new superpowers here. We can write a temporal code Which explains why promises emerge in javascript It's a place where people are constantly dealing with requests that may finish in any order And so I think it's so cool That people using a language so far removed from Haskell ended up solving the problem in pretty much the exact same way And like I said, they're independent discoveries. There's no no plagiarism going on here But I don't think it's a coincidence that they appeared in javascript given the nature of of the language and the ecosystem Right, uh, this is the section on composition and I'm doing pretty well for time So, uh, if you've got questions about about that Feel free to go chuck them in in the forum and I guess we'll just go back to the little little dancing guy again I think we've seen all the facts, but whatever you can watch them again. Try find the fake one I should have bought a rubik's cube or something. I could like solve the rubik's cube while While waiting at least they would have been entertaining This one's cool 23 people in a room to ensure a 50% chance of a shared birthday Tim has put something in the chat. Um, he said it's much easier not to have bugs when your functions don't have side effects And yes, that's very true. Entire classes of bugs simply cannot exist In a purely functional programming language Give it another 30 seconds or so That's a fun one if you're into languages. Preservative means something different in many european languages For the european viewers All right, let's kick on Right, this is the section on composition I mentioned a bit in the previous section, but this is sort of composition in a more abstract philosophical sense So here's a quick explanation of what composition is Um, again, very abstract so say I have three things they can be anything but in this example I'm using coins and so you have some arrows in this case I'm using pipes coins and pipes because video games So if if you can go from there to there from a to b And if you can go from b to c Then the composition of those two things if it exists, which it's not guaranteed to goes from a to b Pretty straightforward I think like you can see from the diagram like obviously if this is a system where composition is possible Because you just go in that pipe in the other pipe and you're at c So yeah, of course if we can pose those things together we get a route from a to c Right who cares what's what's so great about composition What's great about it is that big problems can often be chopped up into smaller problems that are easier to solve And if we can be clever about how we like dice up the problems Um, we can come up with solutions to the individual pieces such that we can put the Solutions together and form a full solution And then this is the cool part you can infinitely speed up the work by simply adding more workers you get them to work in parallel, right? So i'm just going to go back to that diagram So yeah, maybe we want to go from a to c maybe that's our goal to go from a to c But that's like really hard for some reason But maybe someone out there worked at how to go from a to b and someone else worked at how to go from b to c Well, if we're working inside of a system where composition is possible, then we just solve the problem you just compose the two solutions together and you're done And uh, this is I think the natural way humans solve problems We love to you know divide problems up in our heads and then figure out the little bits and put it all back together Okay, here's some examples throughout history of where composition was employed The pyramids, you know, I had lots of people working in parallel To to move those blocks. It wouldn't make any sense to just get one guy to move every single block The large hadron collider is a great one I don't think there's a single person in the world who fully understands how that thing works That was a huge collaborative effort McDonald's Um, I think McDonald's was the first place to have staff make individual parts of a burger And then at the end compose the burger together and that way they could produce way more burgers instead of just having one One guy at the grill making the burgers and uh Moodle does it as well, uh, when we when we do projects. So let's have a think about how Moodle tackles projects um, so Do we get one mega awesome 10 times developer to bash out all the features a little bit like this? Uh, no, I don't know about you, but I wouldn't be keen to work with someone with that sort of attitude So the correct way to write software is of course with your friends as a team So this is why it's worth Spending the time to plan how to chop up the work And we need to make sure we're chopping the thing up into pieces that can be put together later And this is why uh at Moodle we spend all this time planning how we're going to do the work for the releases And um, yeah, this is a takeaway. I I believe composition is nature's greatest hack Uh, I wanted to try and convince you that it's fundamental to the way humans think We're amazing for our ability to do this. Uh, I don't know if there are other animals that break up problems this way And then solve them collaboratively. I think we're the only ones that do it As at its core the composition is about relationships and building complexity by Combining the relationships and hey that sounds familiar again, doesn't it that whole declarative thing that was about relationships So this brings me to One more near the end my final point more or less So when we write programs as an individual in this case, um, we naturally want to break up the problem That's why we have functions in programming in the first place. We don't write, you know, like one big program That's like a novel essentially We want to break the problem up into building blocks that we can put together and mix and match And the building blocks who use matter some compose better than others Um now because of all the restrictions the functional paradigm places on you The lack of mutation the lack of control flow functions in a pure language Naturally, uh, well, they're not well suited. They are they guaranteed to be composable. So I'm just going to go back to that composition slide so Say we have some function that goes from a to b and it has a side effect That means when you call b to c with the result from a to b That is not necessarily the same as calling the composition of those two functions a to c The whole point of the composition is that if you call a to b then b to c That the result should be the same as Calling the composition of them But if the if the database is mutated or something like that in one of the calls those two subsequent calls to the composition Or the one after the other version will have different results The point of composition is that they should be the same and in purely functional language They will be they're guaranteed to be there's no way you can mess it up Um, and I'll I want to make a comment that I think is my opinion I don't know the history of these things, but I'm I'm pretty sure procedures in imperative what we call functions. Um In like php for example are a short sighted attempt at composition It's like people wanted a way to have these building blocks They wanted a way to nicely put things together, but It doesn't quite work unless you're very disciplined and you try to keep the side effects Out of your functions, but as I said in pure language, you can't have the side effects You just cannot have them. It's guaranteed that you have composable building blocks And yeah final little box there. This is becoming super relevant in the age of parallel computing Um, which I'll touch on in a second Um, here's a little bit about why functional program is awesome The thing that I wanted to convince you of to begin with So by taking away these convenient but dangerous tools like the ability to just mutate state to modify the database, whatever Um, we're left with tools that are incredibly powerful But more difficult to wield In particular, we've got a temporality. We can express things independent of time We've got infinity. We we've managed to wrestle infinity And we've got composition the fundamental way human solve problems is now just available at all times. You don't have to worry And here's a couple of final big brain thoughts At Moodle we work across multiple time zones So it's you know, the idea of being able to solve problems in a time independent way seems a bit appealing Um, and Moore's law this one is particularly interesting for those that don't know that's the observation that the number of transistors in cpu's is doubling every year, but that's finishing Now it's um, it's coming to an end. We can't physically cram more Transistors in there And we're now seeing a shift to parallel computing because we you know, you want more you want to double the power You just add another box. I mean imperative paradigms Are not the right the right tool for programs that need to run across multiple computers. They're just not So either I think we'll see a shift to declarative style programming soon But that you know functional program has been saying that since the dawn of time Or we're going to shoot ourselves in the foot and make it hard real quick real fast And I hope we see the the paradigm shift because it's the definition of madness really, isn't it? Like if you do the same thing over and over again, but expect different results And another analogy that comes to mind when I think about these things is like the the frog in boiling water Well, he's not in boiling water. He's in cold water But the water temperature slowly rises so he doesn't notice and then eventually he's just cooked Where we're getting to boiling point. We got it. We got to jump out of that pot soon And here's a really fun one quantum mechanics might be so confusing because at a certain point The universe doesn't want to be chopped up anymore. Like, you know, we kept splitting things We split the atom and then we got like electrons and we started looking into those and then After a little while physicists were like, oh This stuff's starting to behave real weird. I don't like it And maybe it's the case that we just can't understand that our brains want things to be chopped up into small pieces But Does the universe have any obligation to actually be that way? I don't think so And um, yeah, that's that's it. Thank you so much for watching my talk and letting me share my passion for programming with you Um, if nothing else, I hope you're a little bit more curious about functional programming And even though it's not super relevant To Moodle or, you know, probably the kind of code that that you people write on a daily basis I really wouldn't encourage you to investigate it because learning more about it will help you be a better programmer If you have questions, please email me. I'm always always happy to talk about this and I would suggest going to the pub for a drink, but Well, uh, yeah, kovat 19 has other ideas about that And if you have ideas about how I can improve this presentation, as I said, it's a personal project Please get in touch. I I'll be very happy to To take on any any constructive criticism So, yeah, I'm gonna mute my mic now. Otherwise we'll get echoed from chris But thank you very much. I'll be on the forums answering answering your questions Well cam, what can I say? That was very fascinating and even a slightly bit entertaining as well So thanks for that. I learned a lot about how to make a hamburger and I also Found out how many credit cards you might find in a pie Um, I forgot to tell you that I did see Taylor Swift last night. She said to pass on your her regards. So regards Rado. All right, everyone. We've got a bit of a break now before the next one. So Head down to the cafe and have a coffee or a surveyser or whatever tickles your fancy And we'll see you back in the tech room At about 20 or 40 minutes. Thanks a lot