00:00:15.780
All right, it's five past, so I'm going to get started. Before I move on to the content of the talk, I feel like there's something important I need to address: the election. The District of Columbia has sent a petition, or is about to send a petition, to Congress asking to be made a state. This will make the District of Columbia the 51st American state. However, I believe we're missing an opportunity here. Instead, we should consider adding two more places—say, Guam and Puerto Rico—as states. This would bring the total to 53 states, which is a prime number, and America would become a nation indivisible. Thank you.
00:01:11.570
My wife suggested that I open with a joke; that's the only joke you're getting, though. Who here is using keyword arguments in their Ruby code? And who would say they're using keyword arguments enthusiastically in their Ruby code, like in most places? All right, with any luck, this will be one of the most useful presentations you see at this conference. If I do my job right, you will leave here and significantly change the way you write your Ruby code.
00:01:32.310
I would say that keyword arguments are a killer Ruby feature that you're probably not using enough. I've been a software developer for 20 years, and a Ruby developer for 10. I remember being in the room when Twitter was publicly announced for the first time in Austin; that was about when I started using Ruby. I taught at a boot camp for a Ruby web serving framework and have been told that if I mention this framework at this Ruby conference—which isn't about that framework—burly men will come in and drag me out. So, I won't mention the framework. I've also done consulting around that and Postgres, as I've realized that people don't use Postgres and databases well enough in this community. Therefore, I decided to work on a book about that.
00:02:39.419
Here's what we're going to discuss: first, I'll clarify what keyword arguments are and what they do. I'll explain how they can make your code clearer, which might seem simple and obvious, but there's more to say about that than you might think. Then, I'll talk about how keyword arguments can make the functions you write more flexible and functional in a couple of different senses.
00:03:03.090
Let's start with how keyword arguments work. Here's an example of a method declaration in Ruby that demonstrates every possible type of argument. We have a positional required argument, a positional optional argument, splat arguments, a required keyword argument, and an optional keyword argument. There is also a keyword arguments splat, which is an interesting feature. The clever folks who have implemented this feature have done a great job of making it intuitive.
00:03:30.530
You can call a keyword arguments function like this—you can take a hash and call it that way. If you're using something from a while ago, you can still use it that way. One nice feature is that with optional keyword arguments, I can refer to an earlier keyword argument for its default value, which is really nice. You can also splat hashes into other hashes, and all of this is nice, intuitive, and fairly easy to use. A couple of caveats: you must place all positional arguments before the keyword arguments. If your last positional argument is a hash, Ruby can get confused, so be mindful of that.
00:04:45.079
It seems obvious that the primary advantage of keyword arguments is that they lead to clearer code. Here is a method from the Ruby standard library. Unless you've worked with this function very recently, I challenge anyone to tell me what all these arguments are. They correspond to the server you want to hit, its port, the proxy server, the port for the proxy server, and the last two arguments are the username and password for the proxy server.
00:05:10.530
Matz was talking about how Ruby is a human-centered language, and I think we can do better with keyword arguments. Let's imagine a different scenario where the Ruby standard library is rewritten around keyword arguments. If we've experimented with keyword arguments, we might have ended up writing something that looks like this: at a glance, it's a bit better, but there might just be a slight salad of keywords you can't easily differentiate. Although it's a little better, it’s still confusing. Let me be clear: I have tremendous admiration for the conventions established by an influential Ruby book written many years ago. It has guided developers, but to adopt keyword arguments effectively, we need to move beyond that book.
00:06:00.220
If you're going to use keyword arguments and there's more than a couple of them, you should be prepared to write your Ruby code in a clear and straightforward way. Many people have suggested a new formatting style that might initially horrify, but I think it's quite clear. Honestly, I can't envisage a clearer way to express the parameters. I've been advocating for keyword arguments, and while many agree, they often express reluctance due to the effort required to adapt to a new way of working.
00:06:46.690
The clear advantage of keyword arguments is that they offer greater flexibility. The first and most obvious benefit is that optional arguments are, in fact, optional. With positional optional arguments, you must supply them in order, without the ability to skip ahead. Keyword arguments allow you to pass in whichever ones you need, making them strictly more flexible. For example, let’s say I’m using a Ruby web serving framework and calling a render function. If I decide that I need to add new arguments later, such as headers or stripes, I can easily do that while maintaining clarity. Each call can pass in different optional values without confusion. This approach makes the code cleaner and easier to follow.
00:08:11.190
Unlike with positional argument functions, keyword arguments can handle multiple optional parameters without confusion. If your function has several optional parameters, you’ll likely need to switch to a more complex object-oriented solution with an initializer and tracking state; however, keyword arguments allow you to achieve what you're aiming for in a more straightforward manner. Many are moving away from an object-oriented bureaucracy towards a more functional style of programming. My message today emphasizes that keyword arguments invite you to use Ruby in a more functional way. You can easily manage multiple optional parameters, and this is not just fine; it’s a new way forward.
00:09:43.220
I mentioned keyword args splat earlier, which is quite interesting. Let’s say you have a salary calculation function that needs user-specific overrides. You might treat a hash in Ruby as a sort of partially applied or full function. This concept relates to currying, a feature unique to functional programming. You can treat hashes similarly and build functions that can handle customization easily, all while maintaining functional style. This simplifies the process significantly and encourages cleaner coding practices.
00:10:48.000
To summarize, keyword arguments provide clarity, flexibility, and functional style. They invite you to move towards a simpler way of coding, steering us away from you might think of as object-oriented bureaucracy. They are particularly beneficial when refactoring and allow you to write cleaner code. As we adopt these principles, we may find ourselves delivering code that is not only better but easier to maintain in the long run.
00:12:41.030
In conclusion, keyword arguments are clearer, more functional, and offer a flexible design approach that invites a more functional style. They are a tool that can simplify your Ruby code while improving readability. I encourage you to adopt keyword arguments in your coding practices. Thank you all for your attention, and I hope you find this information valuable as you continue your Ruby journey.