 So, this isn't the slide that I'm actually going to start with, but go ahead and you can read it. So, this really starts with a bit of a story, and I guess I could tell another story since we got a little bit of time. I, as introduced, my name is Paul Lamb, and I am from Oklahoma City. And about six months ago, I decided that I would do the minimal thing that I could do to actually get an elixir group started in Oklahoma City. That really involved setting up a website, and I used discourse or something like that that I could just set up in like, you know, 10 minutes, and then tweeted out that we're going to have this Google Hangout like once a month and talk about how to do elixir code. And what's really scary is people started showing up. And we've been doing it about six months now, and I've kept the group kind of small. In fact, I actually put off talking to Johnny on the podcast about it for quite a while because I was really worried that the group would get too big, and really were about 10 people, and on a Google Hangout, that's about what you can handle. So, you know, if you're looking at how to get started, it doesn't really take a lot. And it can be really quite successful. I've also learned that one of the things that we've kind of done is we've used the programming, you know, Brian Hogan's programming exercises book, and people really like to actually look at everybody's code and see how everybody else solved a problem. And every time that I've kind of strayed from that path, it's kind of, it's been good, but it hasn't been as good as actually looking at code and solving problems. So it's a small, like I said, small group, and really kind of how do we get to start thinking about elixir? And that's really kind of where my talk is going to go and how do we approach it. Now, my story starts a few years back. I was in, whoa. I was at a conference that I won't name. It was in Denver, and I got this great photograph down on Larimar Street. But one of the things that I really remember about this conference is that I was sitting, you know, 800 people in a room, and there was a talk on testing, and this person got up, and he was the guy that knew it all. And he spent his 40 minutes basically telling you everything not to do. And I sat there in my chair and thought, holy crap, I do everything he talks about. Everything he talked about was how my testing was set up. And he never once spent a minute on what you should do. And he sat down and it ended. And there was a guy up at the front in front of me that I kind of knew, and I had seen around conferences, had some dinners with, and I kind of tapped him on the shoulder and said, hey, look, my situation is kind of like this. And he was like, oh, yeah, none of that applied to you. It didn't affect you at all. And I was like, oh, well, what am I supposed to do? Probably what you're doing. I was like, OK. So the most important thing in software is that it always depends. There's never, and nothing I'm going to talk about in this talk is a hard and fast rule. And if you think I'm giving you a hard and fast rule, you really don't know me because I am about as anti-rule as you can get. So let's go back to this quote from Jose. And Johnny and I, Johnny was in a Slack channel, and when somehow the group in the Slack channel got to talking about conferences, and Johnny made the comment, great conference talks tell a story. And literally about 10 minutes later, I'm looking on something, and I see this quote from Jose, and it's like, there's my talk right there. I am going to talk about functional explicit elixir. And those, what I've highlighted there, are kind of the important words. Now I think, oh hey, that was cool animation. We might have to see that again. I didn't even know it was in there. Now coming, a lot of us, how many of you came from Ruby? Oh, yeah. So I kind of did too, except I spent a couple years in Scala before that. Due to its roots in functional programming, I think that sometimes as Rubyists, particularly, we look at that and we think of Ruby's influence from Pearl. We don't see that really much in Ruby, but it's there. I'm going to tell you the functional influences in elixir aren't just there, they're the thing that holds it all up. In fact, so I'm from Oklahoma and we have pecan trees. How many of you live somewhere where you have pecan trees? Okay, there's only like four hands in the room. They don't grow just everywhere, right? In fact, there's only like a couple of places within Oklahoma that they really even grow well. What's unique about a pecan tree is that the roots on the pecan tree, it's really just one main tap root. And these trees grow really tall. And the root is as tall as the tree is. It's not like a normal tree where there's about 18 inches of roots or so under the ground. It's literally 90 feet of a root underneath the ground. That's the kind of thing that we have with this relationship with elixir and Erlang. Erlang is holding the tree up. The functional programming side is there all the time. It's not just a minor influence. And I think that's where we kind of, we think, oh yeah, it's, you know, we kind of get sucked into that syntax thinking, oh, it looks like Ruby. And then five minutes later, it's like, ooh, it's not. Or Phoenix is kind of like Grails, but oh shit, it's not at all. So realistically, we have this process of how do we learn to think, how we've all hit new languages, we can all deal with syntax. But learning how to think in that language is what really sets us apart. Now I'm going to interleave, you know, I'm not the only photographer who codes for a living. So I've had to interleave some photographs in here. And I'm going to give you some, I'm going to give you three things that you need to do with kind of a guiding principle. The first one is your code needs to tell a story. Great photographs tell a story. I'm not going to say this is a great photograph, but yes, this is the Oklahoma Capitol and yes, there is a sign that points at it and says that it is the Capitol. There's also an oil well on one side and an Indian on the top of it. There's a story in one frame right there. We're going to talk about pattern matching because Gucci has a pattern and you know it and recognize it. We're going to talk about enum because all good things happen in enum. Now your guiding principle for those three concepts is really Dave Thomas right in the first chapter of the book on elixir, all programming is transformation. You should probably also be hearing Jessica Care in the back of your mind saying data in, data out. It's the same kind of concept. Now I said that I spent a few years in the Scala world and if I was talking about Scala, I would have to and of course it's, I think it's animated too. We'd have to talk about monads and all sorts of stuff and how they're like burritos and anyway. We're not going to do that, but I am going to steal a meme directly from the Scala world and change it up to fit the elixir world. Maybe we could iterate over it. No, we're going to transform that shit. Now in the Scala world, you'd say flat map that shit. We don't have to flat map. So in your mind, all of the principles and all the things that happen in elixir should be around that thought process of how am I transforming data. And I said that our code tells a story and pipelines are what we use to tell that story. Data comes into our pipeline, it is transformed and data goes out of our pipeline. Now since Rob gave that great keynote, there was a tweet by Jose the other day about how great pipelines are in Ecto. We're going to have pipelines in Ecto 2.0 and it got a lot of likes. And Rob was like, hey, wait a minute. I wrote Mobius and it does pipelines and now you're, but I liked Jose's last comment. It's silly. It was silly of me to underestimate how much folks like pipelines. I can't tell you how often or happy it makes me to open up a piece of code and see that pipeline right at the top. And I can see what is going to happen. So let's take a look at a little bit of code. This came off the internet. It's been going around the last few weeks. I've seen it on Twitter and Slack and stuff. It's a LUN algorithm for calculating credit card validity. We're just going to kind of pull some pieces out. Greg Vaughn did this one. He put it out on Rosetta code. Of course I had to change it just a little bit. So if you notice, the first change that I did was actually put the data right at the top. So I see what's going in that pipeline. The next thing I'm going to do is start thinking about the shape. When I'm thinking about a transformation, I actually will do this and I'm actually kind of glad that I see other people do this because it means that I'm not just totally crazy. But I'll actually in the comments just like this show what kind of expected data am I having here? How is this data going to transform? And in each step, what happens? So here I can easily see I've got a credit card that comes in as an integer. We're going to reverse, we're going to take those digits, we're going to turn them into a list. We're going to reverse that list. I'm going to take the list because I'm going to deal with this in chunks. I'm going to split it into chunks of two. I'm then going to do a reduce. In my mind, reduce is always taking a list of things and bringing it down to one. Here I get 43. I'm then going to do and check to see if that actually has a remainder or not. It tells a story. And when we fill in some of those details with our comments of how does that transformation happen, it makes sense. Conversely, I could actually tell a story. This came from Nick, same algorithm. He's taking it as a string. He's bringing it in, pulling some white space off, reversing it. He's actually telling the story to us in English. Both ways work. I tend to use a little bit of both, like he did. I tend to inspire some. If it's a complicated thing, for me personally, this reduce is probably going to come out into a function mainly so that I can test it. Because if there's much inside of any enum function that actually does kind of a transformation for us, if there's much to it, I'm going to pull that out, test it, give it a name. One of the things that makes me sad, and I saw this on a blog post just a couple of days ago, somebody was talking about pipelines and they explained the whole macro behind pipelines and then they went and did some code analysis on like Ecto and Phoenix and some other things and came up with the conclusion that pipelines really aren't used in Elixir. And I really felt sad at that point, really sad at that point. Because when I look at something like Phoenix, Phoenix is designed as a pipeline. From start to finish, it's a pipeline. We think of it, if you've gotten the book, they use pipelines through the whole book to explain it. A connection comes in, it goes through an endpoint, it goes through a router, it goes through the pipelines in that router and it hits a controller. There's no magic in Phoenix. If we want to talk about that magic of those differences between it and Rails, the magic just disappears. It's a pipeline. In fact, when we start breaking that down, it literally is just calling the call method or the call function on each of those plugs and sending it through a pipeline. Here's my quote from the book, plugs are functions. Web applications are pipelines of plugs. Pipelines permeate Elixir, and that's how we tell our story. So let's talk about, there's not a clock anywhere, is there? Okay. It's like, I can go as long as I want, huh? So pattern matching. Pattern matching is one of the coolest things in the whole world. In fact, I can remember years ago, while I was still doing Ruby, there was some, they did some screencasts with Jose for one of the websites, and he's talking about pattern matching and I had no clue what he meant. I mean, there's like three hours of it and he's talking about pattern matching throughout the whole thing. No idea what it was. And then I went and did Scala and it was like, oh, pattern matching, okay. So pattern matching really is just how we can put an expression in other ways and other places than we're used to, outside of, say, just a NIF statement. What's interesting to me is that as I've kind of gone through Elixir school and worked with other people and my own code and then watched the Internet and some of the groups, the number one response almost every time somebody says, well, how would I do this in Elixir? The number one response is you're going to start with a bunch more pattern matching. And usually in my own code, if I'm looking at it and it doesn't seem clear, it doesn't seem concise, the first thing I'm going to do is start pulling that apart. Where am I not really pattern matching that I should be? How can I make that more clear? This is also another one of those posts that came across the Internet and I'm old so I get cranky about what people write and I complain on Twitter too so sorry if some of you have been the recipient of some of my complaints but like I said, I'm getting old. So this is common, this is a real common. The post that I saw last night was he had really learned to embrace the functional side of Elixir more by going through and writing some algorithms and one of them was removing duplicates. And he starts with pattern matching and I pulled out his code so we just see the function heads and we can see, yeah, we start with an empty list, we start with the first element, we see the thought process. If you get in a situation where a parameter to a function should be a thing, make it that thing. Here we've got an integer, it has to be an integer in the first function. In the second function it can be a binary, a string, and it converts it over to an integer force and calls it again. If you have, like this one comes from Rob Ponderis-Mobius, Rob, I love Mobius, it's great. If you need a small DSL for doing web stuff and you don't need all the extra stuff with Ecto, Mobius, Rob's Mobius does a good job. So this comes from Mobius. Here the command object has to be a struct, a query command struct. It has no choice. Make that explicit in your code. When something has to be something, let the compiler help you. Try to stick to some common idioms. What are the common idioms in Alexa? They're still developing to a certain extent. Here's one of them. In a case we tend to look at error conditions. For okay we tend to return a tuple with okay and the value. For error we either return error or we return a tuple in a message. That's kind of a common idiom that's developed within Alexa. There we go. Here. This pipeline starts with a database. This is again from Mobius and says I want to use the user's table. That right there creates a query command struct that then gets passed through all of those other functions. And then finally and basically that query command gets modified and we create a new query command with each one of them. And finally two lists says oh I have a query command but they want a list so I've got to run that query and turn it into a list. That concept of starting with a struct and sending it through the pipeline and transforming it is kind of that essence of Elixir. Here we've got effectively what happens within Phoenix. We take a plug connection which if you look at the struct for that it's kind of large. It's got a lot of fields but it works really well. It simplifies that whole process quite a bit. And from what I understand you might be able, Chris can probably, it's fairly efficient too. The way Erlang actually does the strings we don't really wind up, even though it's immutable we don't really wind up recreating that structure over and over and over again. The strings actually, so it stays really efficient. With with is a new keyword in the language. Just happened about a month ago. When Jose was talking to Johnny a couple of weeks ago he mentioned that yeah it's not really being used much. And Dave Thomas came back and said wait a minute I think we should use it more. And here's the pattern. Again with to me is a pipeline with conditions. So when we need to be able to not just send data through and transform it we've actually got to check conditions and we've actually got to generate other data through that. That's what with becomes. When we look at it it's a way for us to be able to say okay I've got keys that I'm going to start with. And this is literally pulled from Dave Thomas' blog post and I highly recommend you go look at it because it really gives you the thought process there. Then if I don't have those required keys I'm going to actually end that function. But if I do have them I'm going to check the optional keys and then okay I can go on. When we see a with it becomes part of that pipeline. We should think pipeline with conditions in our head. There's a couple of other ways we can use with it's also nice because it keeps some of those variables encapsulated within it. Go read Dave's blog post. Enum, I was running out of pictures to pick with slides and this was the closest I could come with. So it's a transformation of cake into cake balls. Enum is huge, 73 functions right there in the enum package. There is all sorts of things and one of those things coming from the scholar world is that often in other functional programming languages, that difference between somebody new and somebody that's been there a long time is how much do they use out of a package like enum? How well are they using map? How well are they using reduce? Are they using zip and join and all of the other good things in there? Now we had that slide a second ago with the guy writing the deduplicating a list. It made me sad, yeah, this code and I actually included more of his code in there. It made me sad that he didn't just do an enum unique and just clean it up. Because it's really cool that you can write your own and I think that's good. I think it's good for us to understand how that works underneath and I think it's a good programming exercise. But realistically when I'm looking at code, if it just needs to find those unique values and pull out the duplicates, use the built in ones, they're not evil. So here's a few things that are probably going to get us in trouble. There is an alligator up at the top of that picture and it says caution not to swim. Yeah, I know, it's a bit of a stretch and it's early. If and unless, now why do I call these cautionary things? Why am I going to warn you about them? If you get many conditions in your if statement, you're probably not pattern matching correctly. I see a lot of head shaking, yes. If I personally, if I have more than one condition in my if statement, I'm really trying to figure out why shouldn't I be pattern matching? Is there any good reason why I shouldn't be? If there's three, it's red flag warning, I've got a pattern match. Or I've got to create a function that does that for me to get it smaller. Now that's kind of a, I'm saying that kind of like a rule. And like I said, I don't like rules, but it's more of a way to think. Unless, unless it's kind of the same way, who's seen an awful, unless inside Ruby, raise of hands, oh really, that's all? I've seen someone, I've seen some, I've written some, sorry. So, unless the most idiomatic thing that you see with unless is that we raise a condition unless this expression is met. So if we're looking at how do we idiomatically use unless, that's kind of the one that I tend to think of. It's like when I'm getting ready to need to raise an explicit exception, I'll usually bracket it inside an unless. But that's kind of general, you know, there's cases for using an unless. Just watch how many expressions get in there. Means you're not pattern matching. Getting set functions, this is something I like to kind of get cranky about, particularly on Twitter. I can't tell you how many times I see somebody try to recreate objects in Elixir. Don't do that, please, please. We don't have objects in Elixir. We have data that we transform. Now, are there valid getting sets? Oh heck yeah, you know, if you're writing an HTTP library, you're gonna have a get method, right? I mean, there's gonna be valid uses of these things. But when we start moving into, oh, I wanna treat that struct like an object, and I wanna, oh, look, I could actually put that function within that struct and don't do it, all programming is transformation. I've given you kind of the three, that's your mindset. When you're thinking about Elixir, what am I transforming? What am I starting with? Where am I getting to? And those three things are what we're primarily using. Now, the question then comes up is, this is kind of the entry place. What is the mystical guru version of Elixir? Where am I, if this is the kind of mindset that we need to start with, where am I at that transcendent level, that I know it all? Well, in Elixir, that really becomes, do I understand that I'm really working with distributed processes that are supervised, that can fail? It's not recreating your other language in Elixir. It's how do I embrace the fullness of the Erlang system underneath? That's really the mystical guru side of where we're going with Elixir. And when you think, oh, I've done the most creative thing in the world with Elixir, be careful because if you're not kind of going down that path of really understanding, am I dealing with processes, am I dealing with distribution, am I dealing with supervision, you're probably not, you're probably just enjoying your own genius. I'm Paul Lamb, and that's all I have for right now. I'll be here all day. Feel free to come talk to me. I'd like to thank my employer for sponsoring me to be here. And thank you all.