 We're going to get started, but before I go on to the content of the talk, I feel like there's something I have to address which is the election. This is very important. The District of Columbia has sent a petition, or is about to send a petition to the Congress asking to be made a state. This will make the District of Columbia the 51st American state, but I think we're missing an opportunity here. I think what we need to do is pick two more places, Guam and somewhere. Puerto Rico, make them states, because then we'll have 53 states, which is a prime number and America will be a nation indivisible. Thank you, thank you. My wife said I should open with a joke, that's the only joke you're getting, though. Who here is using keyword arguments in their Ruby code? Who here would say they're using keyword arguments enthusiastically in their Ruby code, like in most places? Okay, so with any luck, this will be the most useful presentation or one of that you see at this conference, because if I do my job right here, you will leave here and change the way you write your Ruby code in a significant way. So I say the keyword args is a killer Ruby feature you're not really using. I've been a software developer for 20 years, a Ruby developer for 10, I was in the room when Twitter was publicly announced for the first time in Austin, I believe, it was about when I started using it. I taught at a boot camp for a Ruby web serving framework. I've been told if I mentioned this Ruby web serving framework at this Ruby conference, which isn't about the Ruby web serving framework, that Burley men will come in and drag me out. So I taught at a boot camp for that for about a year, and I do consulting around that and Postgres, and I decided to start work because people don't use Postgres and databases well enough in this community, I'm going to work on a book about that. Here's what we're going to talk about, we're going to make it clear what keyword args are and what they do, how they make your code clearer, which might seem simple and obvious, but there's a little more to say about that than you might think. And then I'm going to talk about how keyword args can make the functions that you're writing more flexible and more functional in a couple of different senses. So let's start with how keyword args work. Here's an example of a method declaration in Ruby that has every possible way or every kind of argument, right? So there's a positional required argument, a positional optional argument, positional argument splat, a required keyword argument, a optional keyword argument, a keyword args splat, which it turns out is super interesting and the block thing. Now, the clever folks who've implemented this feature have done a great job of making it nice and intuitive. So you can call a keyword args function like that, you can take a hash and then call it like that, you can, if you're using something from like a millennia ago in internet time, you can call it like that. Here's a nice feature that I don't believe you can do with positional args. A keyword arg, optional keyword arg can refer to an earlier keyword argument for its default value, which is really nice. And you can splat hashes into other hashes. So that's all very nice and intuitive and simple and fairly easy to use. Couple of caveats, you have to put the positional arguments all before the keyword arguments. And because it does this business of interpolating hashes into the keyword arguments, if your last positional argument is a hash, Ruby can get confused. We're getting nodding over here. So I think it seems obvious that the main thing that you're likely to get out of keyword arguments is that that is clearer. Here is a method that you might call from the Ruby standard library. And unless you've worked with this function very recently, I defy anybody to tell me what all these arguments are, right? They are in fact the server you wanna hit and it's port. The proxy server you wanna use, the port for the proxy server and the last two arguments are no, they're in fact the username and password for the proxy server. Our maths was talking about how Ruby is a human-centered language. And I'm afraid this is bad. We can do better now with keyword arguments. So let's imagine a different world in which the Ruby standard library was rewritten around keyword arguments and what this method call might look like. Now, if you may have experimented with using keyword args and found yourself writing something like that and gone, it's sort of better. But there's just ASCII salad up here. You can't tell at a glance what's a keyword and what's an argument. It's sort of maybe a bit better, but not really. And fair enough, the problem I think is this book. Now let me be clear, I am an enormous admirer of this book. If you have to write any kind of technical book, you could do better than slavishly copy this book in every way you possibly can. Furthermore, I don't think we would be here today if it wasn't for this book. We, well, maths wouldn't be here at all and the rest of us would be at a Java conference or something awful. Not only did it, was it responsible for teaching us all to use Ruby and showing the world what an amazing language it is. But it established a lot of the conventions that we all use, which is one of the delights of using Ruby. You can go and read somebody else's code, because we all use the conventions that were established in this book about how we write identifiers and blocks and all the rest of it. It's established a really nice sort of set of conventions. However, this book was written something like 15 years ago. I don't think they have a version that covers the keyword args feature yet. And in any event, I think the conventions we've all got around formatting our code come from this version of this book. So in some ways, if we are to move on and use these new features, we have to be prepared to move past that book. So if you're going to use keyword arguments, and there's more than like two of them, I think you should be prepared to write your Ruby code like this. People say, many people have suggested this too, like kind of horrified. But I think it's, it is quite clear. In fact, I can't imagine a way of making what you're saying here much clearer. I defy anyone to tell me that the bottom one is better in any way. So I've been going around, since I started really digging into keyword args, I've been going around saying this to people. And they're all like, yeah, okay, sure, it's, you know, it's a bit clearer. But I have to, to make it clear, I have to change the way I work, and I like the way I work, and if I hire new people or show my code to someone else, they're not really going to follow it. And, you know, I kind of really like my buggy whip, and it's fair enough. Like, that's not enough reason to go away from here and start changing everything about the way you write code, right? But there's one advantage you can have, which is that it's clearer. There is a clear advantage, though, to keyword args, which is that they are strictly more flexible than positional arguments. First and most obvious way is that the optional arguments are all actually optional. So with positional optional arguments, you have to supply them left to right. I can't just give the third one. But with keyword arguments, I can pass in whichever ones I happen to need for the job at hand. Keyword argument functions are strictly more flexible. Let's look at an example of what that might look like. Let's say I'm using some sort of a Ruby web serving framework. And I'm calling a controller functions calling a rendering function. And then later on I decide, well, I've got a new controller now and it needs to be able to control what the headers look like. Well, I can add a headers argument to my function, now switching to the new style here in the function definition as well. And now I can pass that in. And later on we decide, well, we would like to be able to control the striping in the table, say. So now I can add a stripes argument and pass that in. Now notice that one controller is passing in one optional argument, the other controller is passing in a different optional argument. And it's all nice and clear and easy to follow. Versus if you tried to do the moral equivalent of that with a positional argument function, you'd do something probably like that. And then you'd call it something like that. And that's obviously harder to follow, but past two or three optional arguments you're just not going to bother, right? You're going to switch to some sort of object oriented solution, which is going to be more complicated. You're going to have an initializer and then state that you've got to track, right? This lets you do things sticking to functions in Ruby. And that's sort of where the industry is going, right? Somewhat away from object oriented bureaucracies and more towards a functional style of programming. And much of my message here today is that keyword args invite you to use Ruby in a more functional sort of style. In fact, I see nothing wrong with having lots of parameters, lots of optional parameters. It'll be a bit long, maybe, but not hard to follow at all, I don't think. If this is a function that does a single thing and there's just a variety of different options for how it should do it, I think this is fine, why not? So keyword args are more flexible and they allow you to rewrite code in one place without having to change all the users more easily than if you'd used positional arguments. There's a term for that, it's called loose coupling. And that ability to have all the sort of assumptions up the top and to change them as you're going, as you need, it's known as dependency injection. And both of these things are better if you write your functions using keyword arguments. In fact, let's imagine that we're back in like 2005, and you're working for a small company that's developing some sort of a Ruby web serving framework, but you have Ruby 2.3 available to you. And they say, we need a quick and dirty solution for an ORM, right? I want something where I can just sort of throw a where clause and an order by clause and it'll generate SQL for me. If you had Ruby 2.3 available rather than the object oriented bureaucracy that you might have done, you could do write a function with a signature much like that. And if you think about turning that into an SQL function expression, it's cake, right? So there's a lot of the time when you would until now have written object oriented classes and all that, this feature invites you to adopt a more functional sort of style. Okay, so I mentioned the keyword ARG splat as being super interesting. So let's start out with the simpler uses of it. Say you have a salary calculation function and then someone comes to you and says, we'd like to be able to override the arguments of that function on a per user basis. So there's a default set of behaviors and certain users get it different. So what you do is you add a JSON field to your user table and you just do that. So what's really nice is that you can treat a hash in Ruby now as a kind of canned partial function or whole function. There's a term in functional programming called curring and Ruby has a curring feature but you can actually treat hashes now as something along those same sort of lines. And if someone says to you, okay, well, I want to be able to write it on a company basis. And then override that on a per user basis if I want, that's also cake. You just add a JSON field to company and you're done. And it's functional. It's more functional in a couple of different senses, right? You're invited to do a functional solution and it's easier and quicker to do. So I hope that's enough to convince you that you might like to leave here and go home and maybe start writing your Ruby a somewhat different way and writing much of it or nearly all of it around keyword arguments because they're just better. Let me now illustrate something a little sort of wacky and crazy that I've discovered. I've not seen this. Anybody else talk about this although I'm sure somebody else has discovered it. But it's a fun sort of interesting thing to look at to end this talk. I call it the context funnel. So here's what it looks like when you use it. And it's just involves putting this star star C for context splat at the end of your functions. In fact, what you do is in all the functions that you're writing and calling, not framework functions that you can't control, you always receive this splat and you always pass it on. So let's see what that lets you do. Say I'm using a Ruby web serving framework and I'm calling a render table function and maybe it looks like this. Now since this is the first function I've called from my code, I'm adding the star star C and in other functions that I call that I've written, I pass it on. And then maybe render row looks something like this. So the parts of my code that I've written in this case are view. I pass that C on to again. And maybe my view starts out looking something like this, right? So I've got this sort of call chain that starts up at the controller with render table and ends with that view. Let's say now in some cases I want to be able to format that last name differently. So this is a sort of moral equivalent of the keyword args for a view, I think, right? So I'm allowing you to set a value if you want and if not I'm giving it a default behavior which is do the same thing we did before, right? Now look what I can do. Back at the top of that call chain without changing anything in between, I can pass in this argument and it gets passed down by all the functions in between because they didn't understand it and they didn't care about it. And it winds up down at the view. This is really interesting to work with, particularly as you're sort of exploring developing code. I was doing something or I was parsing some complicated EDI code and I was writing all these functions and they were digging down inside this. And then I realized down here I needed some value I had from some earlier point in the call chain. And without having to rewrite everything in between, I was able to change that. So this is an example of where a functional programming style and keyword args give you code that's more flexible. Anyway, that was just a little crazy thing I've discovered that I'll put a post on my blog about describing that in more detail. Nearly out of time, but in summary, keyword args are clearer. They are more functional in a couple of different senses. They invite you to write a more functional, simpler style of code much of the time rather than an object-oriented bureaucracy. And they are more flexible.