 Monads, conference without monads, right? So monads are asking the right question. And if we think about monads and ask the right question to ask, well, there's actually only one. What is a monad? And you know, monads, there's a problem with monads. They come with a curse. And the curse is like, once you actually understand what they are, you lose completely ability to explain it to other people. And so if there's one thing that you can take from this talk, so if you go to your next job interview and they ask you what a monad is, you just answer, I know what it is, but I have absolutely no idea how to explain it to you. So that's a job guarantee. Just give me a second. Technical issues. All right. So the curse. Yeah, and I've recently learned what monads are. And I was like, ah, come on. I can explain it, right? Curse. I'll manage. So I applied for this conference. Yeah, they took me in. Awesome. And then two weeks ago, I learned I have 50 minutes for it, so I was like, no, that ain't going to happen. Impossible. And I think I have only 20 minutes. So even though, all right. So back to this question. I mean, we can wonder why even we are asking this question? Why even we bother what monads are? So the origins of these questions come from every company out there in the world doing functional programming. So this is Jim. Jim is a junior developer. He comes to this new work. He's excited. He's going to do Haskell. And yeah, it's going to be cool. And he enters the room of senior developers. This is Jack, senior developer. Haskell, senior developer. And Jim is like, yeah. I mean, I haven't read all the cool books about Haskell that you gave me, but I quickly go through some tutorials on the internet. And I think I know semantics of Haskell. I want to do this first program. I want to do Hello World. So yeah, how do I print stuff to the console? And Jack is like, use IOMonad. And Jim is like, I mean, the origins of the questions are probably like that every single time. So if you're Jack, don't be that guy. I mean, OK, so quickly, if you are that guy, just imagine. So in case you can imagine, if you have a junior developer and the junior developer comes to you and asks you, all right, I can read about one value, but do we have some kind of construct that could be an example reason about many values altogether? Your answer isn't used list monad. You're saying you lose list, or collection, or sequence. Even though list is a monad, you don't necessarily have to tell it's a monad, right? But I'll come to that later. All right, so if you go to the websites about monads and tutorials, you will learn that monads like burritos, astronaut suits, elephants, different kind of different things. I'm not going to do that, hopefully. You can also learn about monads when you apply some knowledge from math. Well, that depends on what kind of background you come from. Because if you know category theory and if you know end of factors and things like that, then this is it. You can go home right now, because that explanation over here should be just enough. For other guys, just stay and we will continue. All right, so I will try to explain to you guys what monads are based on four assumptions. The first assumption is we as developers, we understand code. That's my first assumption. The second one is that it is easier for us to somehow reason about related ideas and then having understanding those related ideas, then we can go with an abstraction over it. And having that abstraction, we can create metaphors. This is where burritos come from, at this point, burritos. And having the abstractions and having the metaphors when we can formalize. If you go from the mathematical, if you have degree in mathematics, then probably this list is also OK. But you go from this point to the third to the second to the first, you have to reverse the list. All right, so let's do this. Code and related ideas. Do you guys know this series, like sitcom? Yeah, awesome sitcom. I love it. I didn't have time to look at the last season or whatever. So imagine that we are living in this world of Big Bang Theory. And we only are undergraduates. So after the university, we just created a startup. And we're going to earn a lot of money doing software. And we came up with this idea that we're going to do an application for mobile devices, Android, iOS, and for the 10 users out there, also for Windows phone. It's going to allow us to quickly find out where our partners are, like my girlfriend or my wife and so on. So it's a simple implementation over here. And imagine that we have a geek. Geek has a name. He also has a partner. And he works at some place. And the workplace has a name. And the address is like a street. And we have to implement our main business logic, so partner lookup method, which takes a geek. And implementation is straightforward. We take the partner. We take the workplace. And we return the street. So imagine that we have a cheesecake factory. We have a university. There's Penny. And learn the way that Penny works at Cheesecake Factory. Leonard works at the university. They are right now all together. And if we call this method and print out the results, we will learn that Leonard can find her girl at the Cheesecake Factory. And Penny can find Leonard at Academic Street 10. Cool, right? It's been like what? Two minutes? We have started. We have to deploy, right? So we go to production, right? And results are outstanding. Yeah, it works. But apparently, there is this one guy over here, Rajesh. And he's like, this application sucks. And we try to wonder why. And we ask our domain experts about it. And they're telling us that from time to time, there are geeks without partners. So, well, they might have dug, but I don't know how it is in the US, but in Poland, that's illegal. So we have university. We have Rajesh. And we call the partner lookup method. And we have an exception. So that sucks. We try to implement that that quickly and to deploy as fast as possible. Probably error somewhere here. Let's try to re-implement that. So we create a new method partner lookup. It takes a geek. We check if it's a null. And if a partner is null. And we slowly building this pyramid of doom, right? Yeah. And if you have the result, we just return it. Without the result, we are saying not count. Let's quickly check if it works. It works. Yay. So we go to production. But we feel that we made something wrong here. Like, I feel dirty at this moment, right? Because I don't know how you guys, I wouldn't like to work this kind of code. So we come up with a new idea, a maybe type. So maybe as a type, it's parametrized by A. It has two different, like, extensions. So we have some, which will basically wrap our value A. And we also have a none, which, well, simply is nothing. And we have a method to lift any value A into our maybe type. And we have, at this point, one method here in our trade, which will be called end them. And end them is a method that takes a function. And that function takes as a parameter our A and returns a new maybe with type B. And we return that maybe B over here. So let's see how that could be implemented. So for some, if we want to implement that signature, all we have to do is we have to lift this value over here with our method F. And whatever is returned by this method, by this function F, we just return. Simple as that. For none, basically, we don't have any value to run our function F over here. So we just return our self. Is that something like you guys understand? Can I go on? Yeah, all right, awesome. So having that, we can now implement our partner lookup method one more time. So we take our gig partner. And we are calling end them method on it. So we're taking a partner from, sorry. So if the value exists, we will take workplace. And having that workplace, we will take street and return it. So whatever that is returned over here will pattern match. If we have street, we will return that street. And if it's unknown, we will simply say it's unknown, not found. We don't have any result. So if we call that method one more time, the results are correct. And we are happy. However, if we look at this method right now, I might argue that if we try to compare it to our previous implementation, the naive implementation, this one is very verbose, like a lot of ceremony around it. We are really doing this thing. And all that, we have to somehow, it's there. We know it, but we try to ignore it. So my question is, can we write a little bit different? So it might be a little bit readable. So my first idea would be to simply, instead of doing pattern matching over here and returning a string, we could actually return a maybe type as well. So because some person that will be working with our method might not be still interested in the value. It might be still using other maybe types and be doing other and then methods over here. The other thing that we could also do is call something. Well, it's called for comprehension. I think in Haskell, it's called do notation or something like that. But basically, it says it's a synthetic sugar over this code over here. So the synthetic sugar looks like this. It goes with a little bit of magic. I will later tell you why, but just for the time being, just ignore it. So this notation over here, it's simply by the compiler, it's reconstructed to that over here. It's done on the compile time. So but basically, it's exactly the same code if you look at it. So we take our geek and we take his partner and if that exists, we look for the workplace and if that exists, we take the street and that value is then again wrapped over our maybe type and which is then returned. So I don't know how you guys feel about it, but once you get used to this notation, it's for my point at least, it's more readable because actually I can read line by line and understand what is happening. All right, so the last question that we might ask ourselves is like, how could I right now print my value over here? I mean, this returns some cake street one, how can I print it? So we might add an additional method we will call within. So that method takes a function which takes our A and returns a B. So in other terms, in other words, we are simply, we are giving ability to reuse existing functions that we have within language or within the libraries, like println. So the implementation and some would be like, just take this f function, apply it to value and then lift it to maybe. And then again, implementation for none would be, will be well, nothing. And so how we can print it out? Well, we just simply call within with our function println and that's basically it. All right, we have to expand our market. So we go to pirates and pirates, they have a problem. That's, that's something I'm familiar with, with I have the same problem, like from time to time. The question is why the run is always gone. The lack of alcohol, right? So we will try to create another application for pirates to keep track of the amount of run that they have on their ships. So imagine that we have our pirate, our pirate has a name and he has many ships over here, some kind of type that you, the definition you will see in a moment. The ship has a name and a hold, in a hold there are barrels, many barrels and a barrel that keeps amount of run within it. So there's our Captain Jack Sparrow, has the two ships, Black Pearl and White Pearl and both of them with holds. One is already empty, wonder why. And the other one still has some alcohol in it. So if I would like, so okay, so trade, we will create many, as I said, with cons and cons is defined as a head, the first value and the rest of the many object. And the same, we can, we need to create information that there's no more any elements, which we'll call empty. So if we want to lift like some number of elements into our type many, this is how we will do it. And then method at within are implemented quite easily. So if we go into within method, well, that's just quite straightforward. We take our function F, we apply it to the head of our many object and then we recursively call within with the same function F to the tail of our many object. If we look at the end method, well, it's pretty similar but the values are both of those, we'll return many. So we need to have some way of concatenating those two together. There's implementation, it's a detail at this point. So the implementation is on the GitHub if anyone is interested. All right, so having that, we have to implement the empty but it's empty, so it's always straightforward. And let's see how we can right now provide our functionality to our new application. So we take a jack and it ships and for each ship we will call ship, hold and take a barrel and having barrel, we will just simply call method barrel amount, which will, and again, this syntax over here can be rewritten using for comprehension. As again, this is exactly the same semantics just written a little bit differently. So ships, holds, barrels, barrels, amount and we have our value, which is like this. Now we can reduce it and have the final amount of RAM for the given pirate. All right, if you look at it because I don't know how much time do I have left? That's my watch. Not that many, all right. So if we look at it, then suddenly there's some pattern that we can see. And the pattern is, we've seen two wrapping classes. All have done and then method and each take a function that can be called on value wrap around it, which can be empty or can be multiple instances of it and so on. As I can think, both of those were examples of a monad. So, and yet again the question, what is a monad? So monad is a box, is a container. It takes a value and wraps that value over it. Box has a common interface, which allows us to do one thing and one thing only, connect sequence of operations over the context, or content of that box. And then method simply means do the next thing. However, what the next thing means depends on the implementation of a monad. So we might be calling the method for existing value. We might not be calling it at all if there's no such value or we might be calling it multiple times on the multiple objects that are being wrapped. All right, so having that and new metaphor created after breaches, we can formalize. So monad is an abstract data type. That's simply what it is. It has two operations and then a unit. You might be saying we haven't seen a unit but we actually did. So whenever we were doing lifting, we were actually calling a method called unit. If you look at the papers and the blogs and the web. So if you look at the internet, this method is actually called and then, but it's called bind. And if you come from Scala, you'll actually use method, they call it flat map for whatever reasons, I don't know. But, so that was just a little bit of magic. So to have full comprehension in Scala, you cannot call your methods in monad bind or and then or whatever. You have to have to call it map. So that magic over here was simply transforming and then method to flat map and within to map. And that's simply it. So if we were using name convention, flat map instead of and then, then we could simply remove the magic and this code would still be working. All right, so monad is a backtrack data type. It has two methods bind and unit and there are some laws around those methods. So the first two laws left identity and right identity, well, they think they're saying that unit method should be act as a natural function over the values. In other words, if you put a value and you create a monad using this unit method, this unit method shouldn't damage the value that you put into the box. That's simply it. And the mathematical rules are over here. The other rule associativity is like binding to functions in succession is the same as binding one function that came as to be determined from them. So it's yet another another loss mathematics. I don't have time to go into them. If you guys are interested, maybe you can later on ask questions because as I said, we have to live without formalism with the stock. So all right, so I hopefully answered the questions. I'm like four minutes after my time, but yeah, I hope you guys enjoyed it. My name is Paweł Szulc. I have a blog, a tweet. If you have questions, I'll be somewhere around Coffee Machine because in Poland right now it's 11 p.m. so I would be sleeping right now. But no, I will be also drinking beer. So if you have any more questions than being drunk, I can be more open. And the last thing, I would like to really thank this company over here. It's a company run by my colleague of mine. They simply paid like half of the travel expenses to get me here. So yeah, cool. All right, thank you very much.