 All right, we're at time. All right, we'll start up. We're going to talk about pokayokes. And this is the first place where we can avoid mistakes is actually by pronouncing it correctly. Right before a talk years ago, I said, someone had corrected me incorrectly. And they told me right before I went into the talk, you say it, pokayoke. And so I went in the whole talk and I said it wrong, which is just the greatest irony. But so pokayoke. And there's me on Twitter, and fnconf17 is our handle. And we're going to jump on into the content. So pokayoke, term from Japanese manufacturing that means mistake-proofing. So this is a picture I took in Nashville. We're going to look at a few examples just in the wild. So this is like pokayoke go or something where you can spot these things out in the wild, these mistake-proofing devices. And so here's one where if you were to drive down into this parking garage in a big van or something where you had a vehicle that was taller than seven feet, you would smash in and you'd get trapped under there and everyone would be honking at you and be horrible. So instead you put this bar, seven feet, you bump in the bar and you know not to drive in. So you take something that could have been a tragedy and you just bump into the thing and someone backs away. So you keep something really awful happening or a simple device. All right, and we have another example here of just manhole cover. So what's the pokayoke here? Does anyone have an idea? Right, right on, that's exactly it. So generally you pick this manhole cover up and you don't have to position it right. They're heavy and you don't have to, you can drop it any direction and it's going to fit right down in there. And two, it's not going to fall down the hole and it's going to, you know, they're heavy. You don't want to have to drive one back up. And so that would be irritating. So it's round. It has constant, same diameter all the way around. And so we have round. And we also have this funny thing here. It's a rollu triangle and manhole cover that also has constant diameter. So the rollu triangle number, which way you go around it, it's always the constant diameter. So you could put this thing up on any side and it wouldn't fall down into the hole either, which is interesting. So this exists in San Francisco. Does anyone have any idea why maybe we have the double pokey okay here? Pop is in San Francisco. Hills. So the people taking off the manhole cover, not just dropping it down in the hole, but if they let the thing roll, well what's going to happen is it's going to roll a couple of, and then it's going to fall over. This one on the left would go down a couple of hundred people by the end of the hill. And so you keep a ceiling steak from looking at the tragedy. And so I want you to start looking for these things in the wild. I want you to look for them in software and ideally it'd be great if you could start building these and this could become your new sport. And so this has been a sport of mine for a decade or so where I've been trying to build these things, trying to find these things and all my API designs fall into this idea of mistake proofing. And so it's a good karma thing because you know you're making the world a little bit safer and you're removing a little bit of tragedy. So the characters behind this term, Shingo, Shigeo Shingo and Taiichi Ono were at Toyota. And here are the books. So Taiichi Ono is the father of the Toyota production system. Really interesting book here on the left. And then Shigeo Shingo, behind the zero quality control and his name is tied closest to the Pokyokes. And then the book in the middle, this thing is really interesting. It's 240 examples that were pulled from different factories of these Pokyokes that were deployed. Okay, so let's start off by asking this question. Are errors unavoidable? And so there's one view that would say, yep, unavoidable, people make mistakes, blame, blame, blame, people do things, blame them. And then we'll detect the mistakes and our final expression and then we'll just let the customers find the mistake and let them yell at us and we'll give them a discount or get them to different customers. That is the most awful path. Everything about that is just wrong. The blame is wrong. Everything is wrong. And so let's move down to this other option. So let's assume that any mistake that people make can be reduced or eliminated. And we do that through training people and building systems based on prevention. Systems based on prevention, Pokyokes. So this is, it's a concept based on respect. It's respect for the workers and respect for the people you're working with. Just respect for humans here because you're saying people, you're not a bad person because you made a mistake. Everyone makes mistakes. And the real fault is when we put too much pressure on people and we have people pinned down and we say, you've got to act like a machine. People aren't machines. They're bad at the things that machines are good at. They're good at things that machines are bad at, at least for now, maybe 30 years and be different. So repetitive tasks, things where vigilance, memory are important. We want to have Pokyokes around this and we want to have people focusing on more important things like building Pokyokes. So the basic functions here around prediction and detection. So recognizing that a defect is about to occur and then doing something about it. Shutting down, low control warning or after a problem's already happened, detecting it and then shutting down flow controller warning. We can see that this is a map going left or right here. So we have a process. We have a prevention Pokyoké. We're gonna basically keep that mistake from happening. So think about FP. Think about all the things that whenever you first picked up your first FP language, the things that you no longer had problems with. So just kind of put those in your head right now and think about these prevention Pokyokés that are there. And then our next stage is around detection. So there's a mistake that's already there. What do we do to keep that mistake from being turned into a defect? And so also think about your code here. Okay, a physical example. We have, this would be in a plan. So we've got this part that's a steel, it has this shape, it has this hole in the bottom left. And we know we wanted to drill a hole in the top right. Okay, so we drill it, it's correct, everything's made. Okay, what happens if the part comes flipped upside down? So this thing, it looks the same other than the hole there. Well, if we do this, we've just created a defect. And so this is a real common model you'll see in the literature around Pokyokés. And so we have, then we can create a jig. We can create this shape that when a correct part lays on top of it, it will fit on top of it and nest on the little bubble that comes in. And then we can create our correct part. Okay, so when it comes in backwards, it's gonna fall down and it won't actually be able to see. And so that would probably keep the drill from activating or if the operator, you know, so it depends on how automated you wanna get, they can be very simple. But these are obviously things, your head's probably already turning now about things in your code that behave like this. So we think type systems, we think, you know, pattern matching. But one big thing I think in FP, this is definitely a thing in lean manufacturing, but valuing mistake-proofing over diligence. And I think that that is something that we get right in the FP communities that you hear people off in the OO spaces talking craftsmanship. And I always give the shivers when I hear people talking about craftsmanship, because I think what they're, there's a blame thing happens. And it's like you're not good enough. You didn't work hard enough. And so it's probably a slob, but the idea of putting everyone to the standard when a computer can catch you, when a device can catch the mistake better than a human can, you're getting foolish. And so there are people that argue that, that I think are just absolutely dead wrong. And so here's a blank here. You can see this is a form that you would define new book Yokei here. We see the improvement after improvement in that book. If you go grab it, there are 240 things dropped in here with little pictures of the before and after. So inside of the book, there are all these funny things where they're defining the best book Yokei. I think I like OK tag inside of Elixir when you call into something, you get your OK and then your values. That's what seems to me like a guide pen. These error detections, alarm, limits, which is counter's checklist. I start thinking about curry. I think about a tuple that's the wrong shade. It doesn't have enough elements in it. I think all these start messing over and you can start seeing how these checklists, how these counters, these different limits start coming in and work. And at the top here hints on, identify items with their characteristics, weight, dimension, shape. This is just straight up types of stuff. It's about, does this shape fit this slot? Then we have detect deviations, procedures and committed processes and detect deviations from these values via detection devices. So here's one, have you ever heard of Wombat? OAM, Erlang Solutions, it's a monitoring tool. So that's what I think of when I think about this bottom one, it's detecting deviations, but we'll move a bit on into diagrams here. There's this one, it's a little small so I'm gonna zoom in. And here we see this list of human errors and causes of defects and there's this causal chain. And the thing about this is that we really careful about causal chains. There's a real problem of hindsight bias. Like when a problem happens, it's pretty easy to find the problem that happened and blame someone and say, oh, Knucklehead did it again instead of actually identifying this process that's behind it or the three steps away. And some things, especially in software, are very complex and it's not as simple as it seems. Hindsight bias makes it seem simpler than it really is. But in this chain, so for simple things like that shape fitting on there, that's where this applies. When we're looking at programming in the small, we're looking at catching these things in the small. Charts like this really help. So the literature, you kind of get a sense of what's here. We can see that these inadvertent errors, so this is like, it's sort of goofed. It's like, I didn't realize I even made the mistake. That's the big chain of most of this there. And so that's what our book of yoke is, you're gonna try to help us with. So mistakes. Let's look at another definition. Does anyone have this book? Okay, this is excellent. Everyone else needs to raise your hand next time you get asked that question. Because this is a brilliant book, it's about design. And design in that sense of ergonomics and oki-okis, it just fits right in with this whole model. But most accidents are attributed to human error, but in almost all cases, human error was the direct result of poor design. And so rather than blaming the person, figure out the process, aim it there. The process, make these go away. And then we can actually save some lives here. Slips and mistakes are two different kinds here. So a mistake is intentional. I admit to do that, it just turns out I was doing the wrong thing. And a slip was, I was trying to do the right thing and I just goofed up, you know? And so we have both those in code and we need to think about the kinds of things that would help our consumers or our API, what will keep us when we're, our own consumer in our code. Like we won't be surprised by our own code later on. And so we're starting to think about, I really like it when empathy starts coming in to mind in the context of FP because it's a really, it's a perfect place for it. Like people on the outside don't really think of us as being empathetic, but we are. We don't want people to have to go through the horrors that they go through and oh oh, and then imperative code. And so that's why we're here. So let's look a bit about mistakes and software development. Okay, so we got Wikipedia talking about bugs here, we've seen bugs, but here's what it's gonna boil down to a lot. We're gonna talk about compile time errors, runtime errors, logic errors, design errors. These design errors are really tricky because we coded to the design, but the design was incomplete and this is where a lot of bugs show up. And so this is tricky. Like, and so we start thinking about different life cycles and spans where these can pop up. So this is our battle and the first tool against these things is our friend immutability. So often, FP land, this is serious. We have immutability. And I want everyone to sort of think for just a second about this idea of immutability, like a thought experiment. So what if you couldn't steal? Not just that it was illegal to steal, a really, really illegal to steal and you'll go to jail for a long time, but what if it was just physically impossible for it to happen? No one could. So you would change a lot about the way you live. I mean, you wouldn't, you'd just leave your laptop wherever you go to the restroom. You wouldn't be dragging your laptop into a dirty bathroom. And so much had changed there. You wouldn't have to lock your house. You wouldn't ever lock your keys in your car because you wouldn't have locks. There wouldn't be locksmiths. You wouldn't have any of these problems. You'd go to the park, could leave your kid on the bench while you went off and did something because no one's gonna steal your kid. Everything, your whole life would be better in a lot of ways if this was impossible. And this is what we get in FP. We have constraints. There are guarantees in FP that other stacks, other languages, they just, they're like, ah, you know, we'll try to be good. We'll recommend you do this. FP, you can't avoid it. It's guaranteed and the tools can count on this. They can live the life of someone in the place where there is no such thing as stealing. Think about threading. Think about all of the things that tools can take advantage of. So, let's look about what you learn in your first computer science class. So, what would this be called? An increment, right? That's an increment. And what would this be called in high school math class? Or when you're like a teenager, your math class. What's this? This is, yeah, you repeat your math. You repeat your class because you just fail, you know, knucklehead. And so, it's funny that kids, they're 16, know a lot more than what they learn in college here because the idea of X equal X plus one is just broken. And so, let's look at immutability here in F sharp. So, we say let X equal five. There, say X equal X plus one. And F sharp agrees with your math teacher. It says, no, that's actually false. That's a false statement. And if we get really nasty about it and we say, no, we're gonna force this assignment to happen. We're gonna pin seven here to X. It's gonna say, this value is not mutable. So, it's not gonna let us do it. Well, except for it's sort of would let us do it. If we were to put the mutable keyword on this. And this is this place where F sharp, there's, it's almost there, but in the space in it's in. It's in the dot net framework. And it couldn't be really, really good. And it couldn't turn this idea, well, not allow mutation ever, ever, ever. So, that was a compromise there. And as a result of that, F sharp gets to, doesn't get to ride on the same bus that you ride on if you're an elixir or a haskell or other places. There are things that it can't do for you that we get over on elixir that you get in haskell, you get in the interest and so on. And so, that's a shame, but it does keep you from getting a lot of bugs. There are lots of protections it gives you, but you know, you've paid the cost of it and you don't get quite as much reward for it. And that's where these things about the absolutes are important, constraints are super important. Talk about a constraint, purity. So, purity, so if we have A goes to B. So, our output of our function is based entirely on the input of our function. We don't reach off in an environment. If we have a pure function, the output is solely based on our input here. And when that's the case, and we can count on that, we can trust that, we get all sorts of good. There's a place where that doesn't happen, and that's in OO LAN. And so, OO LAN, my favorite quote about OO is by Joe Armstrong. He says with OO, the problem with it is you ask OO for a banana, but instead you get the gorilla holding the banana in the whole jungle. And so, you've got the entire environment there. You reach your arm in there and you don't know if it's gonna get torn off or what, because so you've got this class, you have this object, and you put your arm in that method and you're wiggling around putting a value in there. You don't know which constructor that object was created with. You don't know who's called what property setter. You don't know what method was called just before you or how many times you, you don't know any of this stuff. You don't know if there's another thread in their wiggling state. You have all these uncertain things and so you have to code defensively and you have all this stuff, you're pinning around, you have to be a craftsman. And so, you go into that mode of being a craftsman, because if you don't, you're gonna crash. The thing you should do is get out of the mind view. You're in the wrong place whenever you have to worry about gorillas every time you call into a method. And so, a place where you don't have to think about gorillas is Elm. So, Elm has a really beautiful setup here where you have referential transparency, you have purity here. And so, crazy, this builds up on top of, it compiles the JavaScript, it's just, so if you can do that, if you can build something that's clean and pure and compile it to this, then anything's possible. So, you know, whatever they tell you at school, anything's possible. So, here we have Mario and we see our character here. He's hop, hop, hop. And we're seeing the timeline of where he's hop, hop, hopped over time. So, what do we do about time? So, in this case, so every function, if you're referring to the clock, then that's gonna be non-determinant. It's always changing out there, right? But here, we're actually taking time as an input into every function. So, if we hop, we have a hop and also a tick on the time. If we don't hop, we just have a tick on the time. If we walk left, we have a left and a tick on the time. And so, time, time, time is moving. And so, let's see this in action here. So, Mario's walking, walking, walking. We're gonna go time travel debug backwards here. So, we're gonna go back to the beginning here and we're gonna start changing Mario's future here. We're gonna change how high you jump. We're gonna affect gravity here. And so, then we're gonna move through here and see how he plays through. And so, this is absolutely beautiful. Like, how would you do something like this in an OO language, where you were mutating, you just wouldn't have, this is just, it's this territory of these, this is why they can't have nice things. And so, we have nice things here. The Elm folks, they can kick off this time travel debugger and we're off and running. So, if you like, if you like this guy, probably also like this. So, this is a line of business, a boring line of business, Blaba, as Scott Blaschen would refer to it. A version of the previous. And so, if you go to Elmling, the perfect bug report, you can see this out here and it basically lets you go through a to-do tracker and every event is being shown and you can play back with it back and forth. You can see everything that happened because, again, every function call is the inputs are the only thing that affected anything. All right. Oh, so this is our danger with OO is every time we do anything, sometime later, this thing's gonna, we're gonna get shot in the back by ourselves and which is, this is over and over the problem. It's a dangerous place. Even the people associated with the name say it's a dangerous place and this is a way I like to visualize, when you hear the term JavaScript in a functional style or C-Sharp in a functional style or whatever in a functional style, that phrase just really tears me up because on the left, we have these three declarative things, they're hard constraints here. We have a plug in the US, a UK plug and we have an India plug here, lined up and we have an OO plug over here. We have an imperative plug and it's like, hey, we can do the same thing, guys. We're all thuring complete and so that's, we can all have the light bulb come on is what they're saying but they keep on missing the thing that the fact is is we have constraints over on the left and on the right, you're gonna shock yourself and so you're gonna go to the hospital and you're gonna send someone else to the hospital. It's this dangerous, dangerous environment and so every once in a while you'll have this, we became slightly more functional. We introduced lambdas or whatever and so basically what it is, they hooked a ground wire off with the alligator clip and so it just tears me up and so we need to shut that kind of talk down when we can. Politely move them to the right way but we're all in the choir here. Okay, so height forward. So we have this idea of functions and we know that inputs go to outputs and we can change many inputs to outputs to inputs to outputs and here we are. So height forward is using a lot of languages and elixir, it takes the expression on the left and pipes the thing, the output of the expression on the left in as the first implicit argument to the expression on the right and F sharp and Elm and so on is gonna do the same thing other than it's gonna be the implicit last argument to the expression on the right. Okay, so here's a transformation. We're gonna take drink, your oval team is our stream and we're gonna try to transform that into taco, wrapped in tacos and we're gonna yell, drink your oval team and we're gonna snake case things. We're gonna put little snakes into the spaces, okay? And we do this in the normal sort of style and it's horrible really. I mean it's painful, it's, I could actually, when I typed this I had a bug in my code. I missed my tacos, I had it in the wrong function with taking the tacos and so this is the way that a lot of code is written but then you move over and you see what we get here. We have this mistake-proofing device right here. It is really hard to make a mistake whenever you drink your oval team, snake space, wrap in tacos and yell. It's very clear, very obvious and it's not inside out. Union types. Autorated types, those types. So we're also gonna talk a little bit about pattern matching here. So we have C sharp or F sharp, we have our type, shape, circle, square, triangle, rectangle and you can describe a circle by a float, it's radius and so on. And we can then define this get area function here that's gonna take a shape and we're gonna match that shape. We're gonna have this pattern match here and if we hit circle it's gonna destructure that whatever came in into our radius and we'll be able to say pi times radius times radius and so on for the others. That's good, that's clean. And what we have here is this shape, we just have four things it can be. And this is powerful because this is again this thing that has a certain number of slots. If we add ellipse up here to our shape, we're gonna get warnings by the tool. You have this pokey okay that just kicked in and it warned us. You're about to have runtime errors fool. You just added an ellipse and you haven't updated all of your matches all over the place. And so this is excellent. We keep from having these disasters happen here. The tools are able to do this. Another thing they're able to help us with is here if we do something really goofy like say get area of null, well it says shape does not have null as a proper value. Well of course it doesn't because null is ridiculous right? And so an F sharp says make invalid states unrepresentable. And so this is that straight up thing of the pokey okay each thing is just straight up like the jigs that we won't allow the operation to happen if we won't allow the defect to happen. Let's take the same example and look at units of measure. So the United States we mess everything up in the entire world for everyone. And so here we have what all sane countries have the metric system with centimeters. Of course it's in centimeters. And then you've got everyone in the United States and of course it's inches. And so here we come in and so we're gonna handle this. We're gonna have a unit of measure here we're gonna add in it's gonna take a measure all you're gonna take the measure. And now we go down in the bottom we say get area rectangle of two centimeters and three centimeters and we get six cubic or square centimeters. That's nice. And if we say get area rectangle of two centimeters and three inches we see the unit of measure of two centimeters does not match the unit of measure inch. And what we just saw fly by here is the Mars polar orbiter which turned out not to be an orbiter after all it ended up being a lander a very fast lander because they had a unit of measure problem and it wasted years of work millions of dollars and who knows what good research they just went away because some American with inches or something along that was the problem. And so but we have Hokeoke's here that would have kept that from happening. Dependent types. So now we're getting into some really deep territory that I barely know anything about but I know I'm interested in it. So this is Edwin Brady here the inventor of language Idris. And so he says what are types for? They're checking a program has intended properties guiding a programmer towards a correct program and building expressive engineering libraries. This is what we're here for, right? This is this talk, this is Hokeoke's it yells these things. And so Idris has this amazing thing called dependent types in it. And so dependent types lets us so in a normal function we might say, okay this thing takes a list of integers or it takes two lists of integers. Okay that's good we get types saved do we pass it in list of strings that's gonna give us compile error, right? So but here in Idris we can say we're gonna take a vector so a list with a length of it and we're gonna guarantee that at compile time that we're gonna put these guarantees on so that we can match on values. So we're gonna have a compile time error if you call this thing with a vector of six ints and a vector of five ints because it knows it needs to add those two up and so we can set these constraints on values. So values is types. So we see something like that in Erlang where we do pattern matching on constants. We'll see an example of this a little bit later but that's at runtime where you're getting these checks. This is a compile time and it's spooky magic. And so this is my 2018 plan is to actually learn this language because it's just y'all spoke of your case and so I'm grabbing, I have the book, I've already started it and this is my 2018 plan. All right, incorrect docs. So a lot of things incorrect in C-Sharp, a lot of things incorrect in this example but this is on MSDN, I think they've updated it now. It was on MSDN like a month ago. So we have this documentation here E equal O as employee and so what this would be doing is we'd be doing a cast basically it would be saying, oh, we're gonna turn you into an employee and if you can't be turned into, if you're not an employee, E is gonna be equal to null which is really awful anyway. I mean, even if this was a good example, this would be a terrible example because this is a horrible set of things that are happening here but notice what we're doing here in this example saying bar E equal O as employee and we're saying if O is equal to null. So it should be E equal to null, that's our bug here and so what this would allow us to do is we could pass in a burglar class that happen to have a name object or a name property on it and the burglar would come in there and say okay, as a burglar is an employee, E is gonna be null but O is not null so it's gonna fall down the bottom and it's gonna do a name compare and it's gonna say the burglar named Bob is the same as the employee named Bob, let him on in and so that's terrible. So what can we do better? So over on the lizard side we have this idea here of inside of our code or code comments, we put example. That's nice, right? That's show everyone how to use your code but what we have here is really a doc test. So if this is wrong, if this is not true, that's a failed unit test and so we broke the build at this point so if I do a full request and I break a new count and I somehow say it's off by one or something, that build of elixir will never go out the door. You can do this in your own code, it's not specific to the elixir project but in any of your elixir code you can have these doc tests. Very powerful, very nice. Cycles. C-sharp, we have, here's some C-sharp code. This isn't the best C-sharp code I admit, I'm sort of picking on them but they allow it so we're gonna pick on them. So here we have class A depends on B, class A depends also on class C down here and then class B depends on class A, class B depends on class C and then class C depends on A and then class C depends back on B, I think I got that right and something like that, I think it was. Okay, then over on F-sharp, here's what we get. So we've got the same exact construct set up but we get a compile error. It's gonna say nope and it's gonna say nope. Notice the one at the bottom, there's no nope down there. It allows the type C to depend on A and B. It doesn't allow B to depend on C and it doesn't allow A to depend on either one of them. So what we have here is directional compilation. So you can only refer to things that are defined above you. This is a pocoyoke, this keeps cycles from happening. Okay, so you might think it's just a mistake. I thought it was a mistake the first time I bumped into F-sharp and I saw this. I thought they just didn't get done with F-sharp. And so, but then I saw this thing and I was like, okay, this is me being a bonehead because this is intentional. So even on the project, so we have big zoo FS project, notice these files aren't in alphabetical order. So in F-sharp, our projects are defined in the order of dependency. So we can know that common utilities here doesn't depend on anything else in this project. And we can go down to the bottom line of project FS and we can expect to see sub main because it's depending on everything above it. And if we go into the Elephant Washer file here, we can be pretty sure that we can change it without breaking anything above it. But we might have to check and make sure that we're not breaking activity group is powerful. And it's something I wish a lot of the language has but it's this beautiful pocoyoke that I don't see in other places. But this is the culture and F-t. See these interesting things, these things that keep bad things from happening. Concurrency, lots of bad things happen here. There's inverse relationship between delover, seniority and eagerness to take on the threading. We have a different story. Again, we have these tools that create these protections, these things that keep us safe. And the Erlang VM is full of these things. So here we have a group of processes. Each of these isolated processes are running. It's all within the context of Erlang VM, which is an operating system. Really, it's not just language runtime. The Erlang VM is running as each processes that we wrote and they're all out there. They all have their mailboxes. And if they fail, they fail independently. They don't share memory. They don't do anything. They're just out there isolated islands. The only thing they can do is they can send messages. It all happens just through message passing. And it's all happening concurrently here. Not happening in parallel. We're running one core here, right? But if we run multi-core, it's all happening in parallel. And it didn't change. Nothing changed because we have this isolation model here. The rules stay the same. And it's the same place to work. All this code is top-to-bottom sequential code. Easy to think about, even though we have massive concurrence, though we have millions of processes running on a box. We have processes running on multiple boxes. We have supervision. We have links and monitoring. We have all this communication between servers. And we don't have the same kind of problems that you have in the simplest thread pool problem in C-Sharp or Java. It's just remarkable. And again, it's these constraints that we have based on our choices that we put on ourselves. Air handling, tri-catch. So this is just the nuttiest idea, to say, okay, so months from now, I'm gonna predict what weird thing led to this thing that I'm smart enough now to actually guess what's gonna happen and code around it. But I'm gonna put this tri-catch block in here that'll probably figure everything out for me at the time. And so it's like, you're gonna send this agent into the future that's gonna look at this thing that you can't keep in your head. And you're gonna do this in a place where there's mutation and there's threads. And all these problems we've been talking about, I know, oh, and you imagine that's gonna work. And of course, it turns clean code into just a garbage heap. It looks awful. It's the, once you do catch something, quite likely you've got a weird state then to keep on. And eventually the whole thing, this is the problem of why, whenever something goes wrong on the computer, help Destiny say reboot your computer. It's this. And so you reboot your computer because it gets rid of all this trash. Of tri-catches, basically. So let's look at Elixir. It's air handling. Age left intentionally blank. So we don't do a lot of tri-catching in Elixir. The idea is to let it crash. You can do that because of supervision trees. Again, this device here that keeps us out of danger. So here we see at the side over here, we see this process here with these links over here. It's a supervisor, supervising it. And it's being supervised by here. So here's our root-level supervisor, supervising tree. And so we have this message being sent over here. Something about it's poison. And it kills our logic. We didn't handle it well. So then our supervisor basically just restarted us to a good state. And maybe that was a one-time message. Maybe that thing will keep on getting killed and it'll stop getting restarted after a strategy. But this is much cleaner because all that code was just written like there was no concept of an air at all. Code the happy pattern. Not everyone is running on the Erlang DM. And so there's a really nice pattern that Scott Blotchin has a talk on. This is a brilliant one to go off and watch. You can F-sharp for fun and profit, ROP. But this talk is just amazing. And so the idea here is you have functions that you have two paths. You can either exit with a success track or you can, so there's railroad analogy. Like you can always split off. You can have a success track that you exit with a failure track. And you can link these things together. Chunk, chunk, chunk. And then you can have the thing goes through the whole path on the success path. Or it was successful, successful and then it falls down into the fail path. And this keeps us from having to have all these nasty tri-catch groups in there. So this talk, this is one to worth going in. I'm not gonna go into much detail but I'll show you how popular it is that it even does show up in the Elixir community. And so it's been brought over there even though we don't have tri-catches. We don't worry with that. There's still cases of having to match on cases of different events happening. And so what we've done here is a built-in language feature that basically was built around this idea of the railroad-oriented programming. So with, so here we have all of our happy cases here. There we go. So all of our happy cases, okay. This one captures okay and then a user comes back. That's inside of our scope then. So we get to use that user. We fall on, fall on down. And any one of these fails, we're on the failure track, which is down here and then we can match. So this is just a handle validation and that sort of thing. Really nice. How do we match it? So we have this weird thing. So we're in Elixir. This is the examples we made in Elixir and we're looking at this low level idea of binaries in bits. So normally in a territory we would bring out the C compiler and probably create a segfault. We're gonna have a, instead, we're gonna have in this functional language with this declarative model here, we're going to strip into these binary files and we're gonna read this bitmap here which is five pixels. So we have a super zoomed in version of this thing. We have a black pixel, a red pixel, a yellow pixel, blue and white. And it's a 24 bit, five by one pixel. So we're going to do a pattern match. We're gonna say, okay, and then we're gonna capture a bin data. Just off of file read. Red, green, blue file. And we captured that. So our bin data now is equal to this. Okay. We know a little bit about the bitmap format. The first thing we see here is the BM at the left. So that's, we're making it like a literal. We're saying that this first two bytes of this thing has to be BM. So we're gonna go ahead and do this pattern match here and we'll walk through it to make a bit by bit. So our BM here, it matched that, obviously. So that BM, yep, that's it. Then we're going to throw away the next 64 bits because we just don't care what's there. It's header information that we are not interested in right now, but the next part we are interested in. So we're gonna capture the next 32 bits, is a little Indian, to this variable called offset pixels. This is gonna tell us where our pixel data begins. So this is gonna be after all the header data, right? Okay. So it's at 122, as we see up at the top. 7A, so we're gonna throw away the next 32 bits of data. We just don't care what that is. It means something to somebody, we don't care. Then we're gonna do a match off of width and the size 32 bit little Indian. And we can see here that it is five, right? So five wide, and so we're gonna do height. We can see off this match, it's gonna be one, right? So those are what we expected, right? This next one is interesting. So what do we have here? It's 24 size 16 little Indian. We're doing a literal match against 20, this is our color depth. We're saying this file, it better be a 24 bit color depth file, or we don't really know how to deal with it, so we're just gonna fall out. Okay, so we captured that, we threw away the rest of the binary. Didn't care about the pixels. Okay, but now we care about the pixels. Well, we're gonna show basically what we captured here, we're gonna offset 122 width, five, height one. Okay, now we're gonna care about the pixels. What we did is we threw away our offset to pixels bytes through that to the I don't care variable, the underscore there. And then we said everything else, we're gonna capture this variable called pixels. And we're gonna take pixels and we're gonna feed it eight bits, eight bits, eight bits into this 24 bit color depth here. And we're gonna read through the pixels until we've exhausted this. We have this list comprehension here. We're gonna exhaust all of our pixels and we're gonna project them over onto the ride into our RGB. One line, one screen of code. Inside of a REPL, we've parsed this binary structure and we didn't say fall. And so, this is the kind of power that we see in all, this could be, this needs to be ported into F-sharp. This needs to be another FB languages. It's here in Erlang for whatever reason, Elixir for whatever reason, just because of the history. But it's really beautiful. So, let me, I want you to just think about this problem here of like how, why Erlang? Why is this stacked? Why does it have nine nines of uptime and all these success cases whenever you could look at and say, you even have a type system Erlang. And Erlang would say, nope, but I have an operating system. And so, instead, we have another formal set of constraints. And so, the Erlang operating system, the Erlang VM, forces a lot of things that we can depend on in the same way that a type system might help another language. And so, I'm gonna blast through, so this is an interesting document here, quite a computer stop and what can be done about it by Jim Gray. This is tandem computing. And so, this influenced the design of Erlang here. So, this is worth looking at. This is a brilliant book. It's gonna talk about complexity. It's gonna talk about what makes things fail, why some hard things, why we can solve some things with analytic reduction, why some things are bad with stats, and why software usually falls in this category of organized complexity, which is hard. So, a lot of it comes down into these organizations, these hierarchical levels. So, in Erlang, we might see something that looks dangerous. No type system when we're down at the little. But we have these constraints that build up and this whole system of these hierarchies, they feed back and forth. And we end up with structure at a higher level that basically keeps everything all right. And so, instead of being dangerous, it's delicious. No, we go, and so, we get this goodness out of there. So, in a lot of ways, Erlang has this extra step at the right. So, it plays in the space, a lot of languages don't. Elixir plays in the space. It has this extra level of recovery. So, the defect has happened. How do we keep the defect from turning into an outage? Okay, now this is the part I really want to run into here. So, property-based testing. So, writing unit test is a waste of time. And so, this would start fights in some communities. And I'd love to see those fights. Because John Hughes would kick their ass. And so, John Hughes, Papa of QuickCheck. Property-based testing, one of the Haskell behind Haskell. So, here we are inside of Elixir. Def module, we're gonna go back with our color idea here. ColorNamer, nameColor, zero, zero, zero, can be black. NameColor, 255, 255, can be white. NameColor, red, green, blue. If red is greater than green, and red is greater than blue, it's gonna be red. Same thing for greens, greater than red. Green, greater than blue is gonna be green. So, we fall through. And anything else is obviously an impossible color. Like anything else is just ridiculous, right? Okay, so, we go into IEX, we build this thing. We say colorNamer, nameColor, red, ship it. So, we're done, right? We've got our product, we're gonna have our launch. Well, okay, we're more responsible than that. So, what we're gonna do is we're gonna bring out property tests here. And built in into Elixir One Six is property-based testing. It's right in the box, it's right here. And so, we're gonna walk in property check all. So, we have these generators here. Red, green, blue. It's gonna come up with their values to feed into this thing. We're gonna run, we're gonna create 10, or 100,000 unit tests here. And try to just swarm this problem. So, instead of writing one unit test around the edges, we're gonna create 100,000 of them. So, come in through here, run. Run our property-based test. Found one really quickly. We hadn't thought about the case of red and blue both being there. So, we have to have our purple. While we're at it, we'll probably also add yellow and cyan. And now we've exhausted all possibilities and everything should be perfect, right? It thinks about it a little bit longer and it finds 250, so we find gray. So, we've missed this other case here. We're gonna run again. Zero failures. So, we have perfect code here. And John Hughes is down here doing his celebration dance, right? Right in the box on Elixir, these are again tools that you won't see in a lot of other stacks of those places. So, we're at the end here. Value, the state-proofing over diligence. Think about this. You've got, on this side, you've got karma where you're helping the world. On this side, you've got spaghetti where you're not really helping anything. And take your sport, go off and do awesome things with it, and I'm glad that you all are in this room and I'm gonna be using your code. So, we're out of time and so throw questions at me on Twitter. I'd love to keep in touch. So, and also help yourself to the Google clusters even if you were too busy, you know, listening to Tweet or anything. And if you want to keep in touch, I will say I have cards up here. I'm gonna get off the stage the next person can pop up here. Thank you all.