Russ Olsen
Russ Olsen
Safari: Design patterns are an important concept in programming as they provide repeatable solutions to design problems. What motivated you to write a book about design patterns using Ruby?
Olsen: About a year and a half ago I was teaching Ruby to a group of experienced Java programmers. We were doing the typical "here's what a variable looks like in Ruby" and "here's how you create a class" kind of thing and it was getting just a bit boring. So one week, just for a change, I gave a talk on how you might implement some of the original 'Gang of Four' (GoF) design patterns in Ruby. The reaction from the class was startling - they were suddenly awake and criticizing and asking questions, and I think we all learned quite a lot about Ruby in that one hour.
It struck me that the design patterns approach peaked the interest of the class because it was familiar ground - most Java programmers know something about design patterns - and because in talking about patterns in Ruby we were up out of the weeds of the language details and discussing the things that software engineers really care about, things like design and encapsulation and code clarity. So when the possibility of writing a book came along I hit on the idea of trying to reproduce that magic hour with the class in print, to try to make the elegance of Ruby come alive by writing about design patterns. The long format of a book meant that I could introduce Ruby to people who weren't familiar with the language along with explaining the more popular design patterns. I could even talk about newer design patterns, the ones that you see popping up in Ruby. But the best part was that I could keep the discussion at that slightly higher, but much more interesting, level.
Safari: Are Design Patterns still relevant in Ruby?
Olsen: Yes and no. The GoF did two things in Design Patterns: Elements of Reusable Object-Oriented Software. First, they introduced most of us to the idea of a design pattern, a repeatable bite-sized solution to a common problem. Second, then they went off and found and explained 23 actual instances of design patterns, things like factories and observers.
So if you ask me if all 23 of the original GoF patterns are still relevant in Ruby, the answer is no. Mostly the GoF patterns were built for C++ and Ruby is a much more powerful language than C++. That power means that some of the actual GoF patterns - factories come to mind - are not terribly relevant in Ruby. They were built for a different time, a different technology.
Still, a lot of those old patterns remain relevant. Thankfully they are easier to implement in Ruby, but they are as useful as ever. But as we adopt a new technology like Ruby, the broader idea of design patterns as little prepackaged nuggets of coding wisdom is more, not less, important. Right now we are trying to figure out the best way of applying all the power of Ruby to solve our everyday problems. It's quite likely we are initially going to get a lot of it wrong. When we do occasionally get something right, it would help enormously if we could package up and share that new bit of wisdom.
Safari: What were some of the greatest challenges in coming up with the standard design patterns in Ruby? Patterns like singleton and observer seem pretty simple. Were there any patterns that were particularly difficult to implement in Ruby?
Olsen: The two GoF factory patterns nearly drove me nuts, but not because they are hard to implement in Ruby. The original factory patterns are all about getting your hands on the right object at the right time. This "getting hold of the right object" problem is one of the fundamental issues of object oriented programming. For example, if I am writing a payroll program, I might have one object for computing Virginia income taxes and a different one for Maryland income taxes. For any given employee I need to figure out where he or she lives and lay my hands on the appropriate tax computing object for that state. It turns out that in complex systems laying your hands on the right object can get pretty difficult. The GoF factory patterns were both designed for a language where classes were static - your program has a definite set of classes to choose from, so when you needed a new object you somehow picked a class from the limited menu and made a new object from the class.
The trouble is, if you look at real Ruby programs there is almost nothing that looks like either of the GoF factory patterns. The reason that you don't find factories in Ruby is that the language is so flexible that you can solve the "getting hold of the right object" problem another way. Actually a number of other ways. In Ruby, classes are just ordinary objects: you can store them, you can copy them, you can modify them, you can cook up brand new classes at run time. You can even modify the behavior of individual objects independently of their class. All of this flexibility means you have a much richer menu to choose from when you need that new object. Which is great for writing programs.
But maybe not so good for writing a book like mine. I couldn't just ignore the factory patterns - folks coming from a language like C# or Java are used to solving this problem with factories, and they are going to want to know how you do that in Ruby. What I did in the book is demonstrate how to build the traditional factory patterns in Ruby (it's easy) and then take the reader through the thought process that starts with factories and ends at the more dynamic techniques that you really do find in Ruby code.
Safari: What is your opinion about the future of Ruby? Will it continue to grow in importance and usage?
Olsen: It is amazing how Ruby has taken off in the last few years. When I started with the language, the common reaction was "What's Ruby?" People don't say that anymore. I think Ruby's success is well deserved - Ruby is such a pleasant language. I think it was Xandy Johnson who said that the best part of learning Ruby is that your first guess at how something works in Ruby is probably right.
I suspect that Ruby will have a long and productive life. But to me it doesn't matter if Ruby goes out of fashion tomorrow - well maybe not tomorrow - but it would be OK if it went out of fashion right after the book sells out. It doesn't matter to me if Ruby disappears because Ruby has already done something that I hoped would happen for years: it has awaken the larger software engineering world to the power of dynamic languages. Because of Ruby, you can go to Java conferences and hear conversations about JRuby and Groovy (a very dynamic Ruby-like language) and debates about the merits of dynamic typing. By no means is everyone convinced (yet!) but I never thought that we would ever even get the conversation started. I think all of this came about because of the excitement generated by Ruby and Rails.
Safari: You wrote a popular blog post on this topic back in February of last year. Is it fair to say that the post was the inspiration for this book project? Did you know when you wrote the post that you had an entire book inside you on Ruby design patterns?
Olsen: The book definitely grew out of that blog article. As I said, I had this great session with my Ruby class talking about design patterns. At the time I was also trying to do a weekly post for my blog, so I dashed off an article based on that one lecture. I really didn't think anything would come of it - I just kind of pounded it out. It was a bit later, when Chris Guzikowski (of Addison-Wesley) hunted me down and suggested that I write a book based on the article, that I really began to think of the possibilities. Chris has this endearing way of just coming to the point, so he called me up out of the blue and said "Hey I see you wrote 800 words on this topic. Can you write 80,000?"
Safari: You wrote in the introduction to that post that a good programming language should make design patterns very easy to implement. "An ideal language would so thoroughly integrate the patterns that they would almost disappear from sight." How well does Ruby fare here?
Olsen: In a sense it is an impossible goal. Every programming language enables you to do a certain set of things very easily. Everything else you need to construct more or less by hand. For example, 40 years ago people wrote of lot of programs in assembly language. If you are writing in assembler, then adding two numbers together is easy, but you need to do a bit of programming to build something even slightly more complex, perhaps a loop. By the time that the GoF wrote Design Patterns, most of the industry had moved on to C++ and building a loop by hand was ancient history. In the era when Design Patterns was published, the problems were more about pulling together coherent object oriented programs.
Unfortunately Design Patterns was written more than a decade ago, and if you stick to the 'mainstream' languages like Java or C#, we really haven't made much progress. Implementing a GoF pattern in Java in 2007 is about as difficult as implementing a GoF pattern in C++ in 1995. In contrast, Ruby makes short work of many of the original GoF design patterns. Iterators, observers, proxies, singletons, and commands come to mind as patterns that become so easy in Ruby that you tend not to think of them as patterns anymore. In that sense those patterns have all but disappeared in Ruby. Oh they are still there, just like we still have loops, but we don't have to work at them anymore. Some of the other GoF patterns - here again the factories come to mind - are reasonably irrelevant in Ruby. There are better ways.
Does that mean we are done? Of course not. We didn't declare victory when we took the drudgery out of building loops by hand. We moved on to tackling bigger problems. The really exciting thing about Ruby is that it allows us to finally say, "Right, we have taken care of the iterators and observers, proxies and singletons. What's next?"
Safari: Your book introduces some new design patterns that are specific to Ruby. Can you briefly tell us about these?
Olsen: The Ruby specific design patterns are exactly what I had in mind when I said, "What's next?" In the book I tackle three design patterns that you see in Ruby programs. The first is the internal domain specific language or DSL. This pattern isn't really Ruby specific but it is very popular in Ruby. The idea behind an internal DSL is that instead of blundering ahead to solve your problem directly, you transform Ruby into a language that makes solving that kind of problem easy. It's all very Zen.
The second one is metaprogramming - which essentially means writing code that writes or changes other code. Metaprogramming is the pixie dust behind a lot of the Rails magic. Again, people have been doing metaprogramming in various languages for years, so it is not terribly Ruby specific, but the Ruby folks have taken to it with a vengeance.
The final pattern is one that is perhaps an original Ruby - or rather Rails - production, and the cure for the XML configuration blues: convention over configuration. Convention over configuration is the perfect illustration of just how uncommon common sense really is. For years we have been requiring programmers to write these tremendously complex configuration files to get anything to work. Convention over configuration starts by asking a very simple question: what if we didn't do that? What if we built applications and frameworks that tried to figure out what the programmer wanted to do and just got on with doing it? If metaprogramming is the pixie dust behind Rails, than convention over configuration is the flying carpet - you're there before you know it.
Safari: Design Patterns in Ruby is currently available in the Safari Rough Cuts program, where readers can get access to material from the book as it's being written. What do you think of this program and how has your experience been with providing access to your material before the book is finalized?
Olsen: From my own selfish point of view as an author struggling to finish a book, the main benefit of the Rough Cuts program was that it gave me slightly more of a reason to live. During all those months hacking away at the manuscript I was comforted by the thought that I didn't have to wait for the actual printing press to turn before the book saw the light of day. Once the manuscript got to a certain point of polish it could go out the door electronically via Rough Cuts.
More seriously, while I don't know a lot about publishing as a business, I can't help but think that electronic content delivery programs like Safari Rough Cuts are the future.
Safari: Your personal blog has an interesting name, "Technology As If People Mattered." Why did you call your site that, and what does it mean to you?
Olsen: The name comes from the subtitle of a book that I read in college. The book was called Small Is Beautiful, Economics As If People Mattered by E. F. Schumacher. Small Is Beautiful is all about how the modern study of economics simply ignores most of what people hold dear, things like love and dignity and the passion for doing things well. I don't really know all that much about economics, but over the years I have seen the same kind of blindness to human nature and human values in software development. We in software development tend to talk about resources when we mean people, and 'level of effort' when we mean someone sweating through a difficult problem. Because of the technical complexities involved it is easy to miss the fact that software development is a very labor intensive proposition and that frequently the software world will veer off in a particular direction more because of the human factors than any 'real' technical reason.
For example, why has Ruby become so popular lately? There are many languages around - Smalltalk comes to mind - that are just as flexible and powerful and got there first. But the Smalltalk syntax looks strange and forbidding to a Java or C++ programmer; by comparison the Ruby syntax seems familiar and friendly. In addition, Rails came along at the very moment when the frustration over the difficulties of building webapps in Java was at its peak. So living, breathing human beings picked the solution that seemed the best way to solve the problem at hand. It's so easy to ignore the human side of things and say in the abstract that this or that language or tool is technically better, as if the people just didn't matter. But the people are just as real as any of the technical issues. And they do matter.
'Technology as if people mattered' also means that we should not pretend to be like the machines that we program. I think that so many technical books are deadly dull because the authors try to eliminate any evidence that they were actually written by an actual human being. It is all 'consider this' and 'therefore that' without a hint of passion or surprise or enthusiasm. But go find a Friday happy hour near some tech company and the room will be full of people arguing about static vs. dynamic typing or whether Java really has pointers, arguing loudly with their faces so close that they are spitting on each other. Inside that introverted shell we techies are really a pretty passionate bunch.
In the book, along with trying to explain Ruby and design patterns, I have tried to get across - or at least not hide - the fact that there is a real person back here. Like most techies I live and breath this stuff, and I think the best technical books are the ones that give you a glimpse of the obsessed mad man pounding away at the keyboard.
