Russ Olsen's new book "Eloquent Ruby" is aimed at Ruby programmers who know the language and іts ecosystem, but are still figuring out the idiomatic ways of writing Ruby code.
InfoQ talked to the author of "Eloquent Ruby", Russ Olsen, about the practical advice given in the book.
InfoQ: Do you know of and use any tools that can detect Ruby code that's not eloquent?
Russ Olsen: Surprisingly, some of the key tools for detecting less-than-ideal Ruby code are the testing tools: rspec, rcov and perhaps Test::Unit. The Ruby community's attitude about testing can be summed up in a few words: It ain't done if there's no tests. Along with ensuring that the code actually works - always a good thing - having good test coverage means that your code is actually testable, which pushes it towards good things like single minded classes full of small methods. A more conventional answer would include tools like flog which will score your code for complexity, flay which looks for duplicated code and reek which looks for specific code smells.
Honestly, other than the testing tools, I don't use these utilities much. The thing with Ruby is that you can get an awful lot done with very little code, which means that many Ruby projects consist of small teams working on relatively small code bases. Because of that, I think most Ruby code quality inspections are done with the Mark I Eyeball.
InfoQ: You mention some of your influences, eg. Kent Beck's book "Smalltalk Best Practice Patterns". What are some of the lessons you learned from these sources? Tips for structuring code snippets or for code organization?
Russ Olsen: There are two very different things that the Ruby programmer can learn from books like Beck's Smalltalk Best Practice Patterns or Bloch's Effective Java. On the one hand you can pick up specific tips and techniques: For example, Beck is where I first came across the Composed Method idea while Bloch's is the last word on the Hell that is equality in an object oriented language.
But there's more to it than that: Programmers have been telling each other for a long time that one way to get better is to learn a new programming language, even if you don't plan on using that language tomorrow or ever. Thus we have books like Bruce Tate's Seven Languages In Seven Weeks, which I think is right on the money.
I see diving into the how-to books from other programming languages as just an extension of the same process: If simply learning Clojure or Smalltalk is worthwhile, then surely understanding how Clojurites or Smalltalkers deal with real problems is also going to be valuable.
InfoQ: The book mentions using hooks like self.included(foo) etc. In what circumstances should developers fall back to these hooks?
Russ Olsen: The hooks are a lot like the call-backs that web programmers use when they are doing JavaScript, the things that let you know that a page has been loaded or a link has been clicked. Only in Ruby can you find out when a subclass is created or a module is included in a class or the interpreter is about to exit. In exactly the same way that JavaScript programmers have come up with interesting uses for their call-backs, Ruby programmers have made use of the hooks to do some really nifty things. For example, it's sometimes handy to be able to keep track of all the subclasses of a class, so that you can pick the right one for the circumstances. As they say in the iPhone world, there's a hook for that. In the same spirit, a lot of Ruby DSLs have no visible main program - things just seem to start themselves by magic. There are a couple of ways that you can do this, but one is to latch onto the at_exit hook and simply kick off the DSL processing at the moment when the Ruby interpreter decides that there is no more to do and it is time to exit.
InfoQ: The book contains a lot of information and advice about metaprogramming. One feature request that has repeatedly come up in the Ruby community іs support for LISP-style macros. What's your opinion on adding some kind of macro feature to Ruby, maybe a la Groovy's AST transformations?
Russ Olsen: I have mixed feelings about LISP-style macros in non-LISP languages like Ruby. On the one hand, since LISP macros allow the programmer to transform the code before the parser sees it, LISP macros let you do some remarkable things.
On the other hand, I think that macros work well in LISP because in LISP the AST *is* the program. In other languages macros make you go through a mental translation from the code to the AST to the transformed or 'macro-ed' AST. I'm not sure that doing all of that has many advantages over the kind of metaprogramming that is popular in Ruby right now. Think about it: Armed with the current set of metaprogramming tools - open classes, the reflection APIs, the eval family of functions and code blocks - Ruby programmers have managed to come up with Rake, Rspec and ActiveRecord. And, while these are all really solid bits of work, the metaprogramming behind them is not very difficult. In fact, Eloquent Ruby covers metaprogramming well enough to get a Ruby programmer started on their own Rake or Rspec style DSL.
InfoQ: How can programmers know if they're over-engineering a metaprogramming solution where something simpler would suffice? Do you know of telltale signs that indicate that it's time to exchange the instance_evals for something simpler?
Russ Olsen: If I could be granted one wish, it would be that the word 'metaprogramming' would disappear from our collective vocabulary. The programming techniques that we call 'metaprogramming' are really no different than the stuff we have been doing for years in Java or C#. The traditional programming constructs, things like methods and classes and variables are all there to help us make the computer do what we want the computer to do. It's really no different with open classes, blocks and eval. They are all just there to help us get the job done. The difference is that some of these techniques are familiar and some - for most of us - are still shiny and new. There is no physical event horizon between regular programming and metaprogramming - it's all just programming.
So how do you tell if you are over-engineering some metaprogramming solution? In exactly the same way you can tell that you are over-doing it with classes or design patterns or any of the other tools out there. You ask if the metaprgramming solution might not save so much conventional coding that it's worth the trip. You ask if the more conventional design might not work just as well and be easier for the next programmer - who might well be you - to understand. You say to yourself, "Hey, is this the simplest thing that could work?" and then you listen to the answer.
InfoQ: Any future or current projects you'd like to mention (books, open source projects etc).
Russ Olsen: Well, with the book finished I'm working on a redesign and relaunch of my 'Technology As If People Mattered' blog at russolsen.com. I'm also looking to do some screen or podcasting, but no definite plans on that front yet. Stay tuned!
InfoQ: Any other languages you'd like to give the "Eloquent X" treatment?
Russ Olsen: Actually I'm thinking about giving English a try. Being a working techie in the early 21st century is one of those worst of times, best of times kind of things. In one way it is great: There's so much new technology coming out and it's all coming so fast, we are like kids in the world's greatest candy store. When I look at my list of things that I should know more about, it starts with Erlang and runs through Clojure and JQuery and node.js and MongoDB and a million other things.
The downside is that all this new tech is threatening to make idiots of us all: It's coming on so fast that simply keeping up is getting harder and harder. So when I watch a screencast or listen to a conference talk or read an article, I just want to cheer for this person who is taking the time to try and explain things to the rest of us.
Sometimes I also want to cry. Having written two books, I can tell you that explaining things is not easy. Explaining things without confusing or boring your listener/reader to tears is even harder. Technical people who are trying to explain their work or their field have the advantage of knowing what they are talking about, but that's really not enough. Crafting good explanations is an art in itself, one that we need to get better at it or all this great new stuff is simply going to overwhelm us.
So I'm thinking that I might contribute to the cause by writing a book about explaining technology. But I promise I won't call it 'Eloquent English'.
About the Book Author
Russ Olsen is author of two books in the Addison-Wesley Professional Ruby Series: "Eloquent Ruby" (ISBN 0321584104, February 2011) and "Design Patterns in Ruby" (ISBN 0321490452, December 2007). For more info on both, please visit the publisher site.