For the past three months, we’ve met two of Matsumoto “⁠Matz⁠”⁠ Yukihiro’s favorite authors, Bruce Tate and Chad Fowler, and one of his publishers, Andy Hunt. We conclude the series with this second of a two-part interview with Hunt’s business partner and co-author, Dave Thomas. Among his six books is Programming Ruby: The Pragmatic Programmers' Guide, the definitive English language reference, which is better known as “⁠The Pickaxe book.”

How did your early efforts to explain Ruby to English-language readers become such a monster effort?

Even the first version of Pickaxe was about 500 pages, and the current version is 919 pages. That is not all my fault. Ruby has grown, and the size of the book correlates remarkably to Ruby’s exponential growth. Whether you look at the size of the downloads or at the number of built-in methods, by every measure, Ruby keeps growing. People keep bolting new stuff into it. It breaks my heart because every time they do that, I’ve got to document it. In the first couple of editions, I tried to document everything. But I’ve had to give that up because the book would be unshippable.

Were you the first to document Ruby in English?

There was some English-language documentation packaged with the interpreter download, but I think I was the first person to create something standalone and comprehensive. There were other people playing with Ruby, but no one tried to document it, to my knowledge. When I worked on the first edition, I didn’t have any documentation of the actual classes and methods that came with Ruby: what was in String, what was in Array, what was in Hash. To produce that documentation, I had to sit down and reverse engineer the C code. The process involved trying to envision how the language behaves. If I pass this kind of parameter, then this happens. Otherwise, that happens. That is why, particularly in the early days, some of the descriptions are a bit funky. I was documenting the mechanics, but it was hard to see the bigger picture of why this behavior. I only figured that out in later editions.

How about the size of your readership. How fast did it grow?

At first, only slowly. The first Pickaxe was published by Addison-Wesley, bless them, because they had published The Pragmatic Programmer. Initially, the Pickaxe sold poorly. So we asked the publisher if we could release it for free as an HTML document. They gave us the rights, and in so doing, they helped the community grow. I spent a couple of months converting the raw text into HTML, which I put up on a website. I think that gave people something they could point to.

Ruby grew from there, but fairly linearly. If you look at the metrics, from book sales to newsgroup posts, I think the growth in Ruby interest is linear from 2001 up through 2005. Then this guy from Denmark comes along and ruins it all by releasing Rails. Suddenly you see a serious elbow in the curve. A lot of that was people who came in never really knowing that there was anything called Ruby―they just wanted to do Rails. That was the tipping point, I think. People jumped on Rails. And some of those people stayed for Ruby. Now we’re seeing a lot of people who are getting some serious chops in Ruby and they are doing some really interesting stuff that is not directly Rails-related--both in terms of web frameworks, but also in other systems.

Indeed we are seeing a whole bunch of nice stuff being written in Ruby, which is gratifying. People are using it as an automation language for devices. And obviously they are using Ruby for all kinds of Web stuff. There are a lot of people experimenting with different techniques. I also think the Ruby community is the most sophisticated in the world when it comes to code testing. There is near universal adoption of some kind of testing by just about every Ruby project, and that’s impressive. The interpreter even comes bundled with a testing framework. Rails builds that into every app, and we now have half-a-dozen decent testing frameworks. There are more mock object frameworks than you can shake a stick at. There are browser-based user-side testing tools. So there is no excuse for not doing testing in Ruby, and in general, testing in Ruby is fun.

Fun? Really?

One of the cool things about Ruby that you can set up the environment for a test with a lot less struggle than with a more static language. If you are writing a test in Java, you can often spend half a page of code just getting to the point where you can call the appropriate object. In Ruby it is a lot, lot easier. Maybe you need to parse some obscure object, but for the test, you can get away with just parsing a string. That makes it much easier to get stuff done, which means that people actually do it.

Your example raises a point Matz talks about: programmer happiness.

The LISP folks would probably say they do the same kind of thing, but happiness is certainly a great focus of his, and I know exactly what he means. There is a certain quality to Ruby, which is very hard to put your finger on, that does make you happy when you are coding. It is interesting that a lot of that quality comes from the contradictions in the language―the fact that it is not precise. It is not small and well specified. It’s kind of large and a bit sloppy at times, and that is part of what makes Ruby fun, because it surprises you. The trick Matz has come up with is that Ruby surprises you in a nice way, as opposed to all those other languages that surprise you in a really bad way.

You are not orthodox when it comes to the future of Ruby. You have encouraged forks.

I was thinking about how Ruby has grown a lot. The internals of interpreter have grown staggeringly. That has made it very hard to experiment with the language itself. I want to see a whole bunch of innovation in Ruby, so I’ve argued that people don’t have to be absolutely compatible with it. There is nothing religious about this. There is no canonical version. I think you should just get in there and hack, do experiments, and get rid of the stuff you are not interested in. If you don’t need regular expressions, floating point numbers, internationalization--if stripping them out would make your life a lot easier when you are playing around with the object model--you should do it.

And indeed there have been productive forks. Inside the current interpreter is a fundamentally new engine, called YARV--Yet Another Ruby VM, written by Koichi Sasada--that came about from a fork of Ruby. They rolled it back in again for Ruby 1.9 because this interpreter was better than the original.

You are also not orthodox when it comes to Ruby “loyalty.” For example, some people were upset when Twitter moved off the language.

I don’t care what they use. Why would people feel upset if someone makes a decision to use a particular programming language? What kind of very sad, lonely person worries about that? People use what they use because it works for them. I don’t see why some people would feel threatened because Twitter makes a choice that is different from yours.

You advocate what you call “CodeKata”--programmers doing practice sessions, much like a musician or an athlete. You wrote: “Greatness comes from practicing, applying the theory over and over again, using feedback to get better every time.”

There’s a famous book, Structure and Interpretation of Computer Programs, which explains the theory of programming using a set of very straightforward examples that grow in complexity. Most of the people that I respect in this industry will go back to that book every three or four years, and run through the exercises. The book uses a dialect of LISP, but they’ll recode it in whatever they happen to be using at the time―be it Haskell or Ruby―and use those exercises as a benchmark for knowing the language.

Because you always get something new out of it and see things a bit differently. And because the exercises help cement the language in your head: going back to first principles always helps ground you in whatever you are doing. I teach Pragmatic Studio classes on Ruby and Rails. I’ve done dozens of sessions, but every time I still learn something. In some cases, I learn a lot. I’ll be doing a basic introductory studio and someone will ask why I do something in a certain way. I’ll reflexively respond: “⁠well, obviously.....⁠”⁠ then half way through, I realize that my approach may not be so obvious. Sometimes, I realize there may actually be a better way.

People always say that having an apprentice is a great way of learning, that by teaching someone, you learn a phenomenal amount. I think of CodeKata as a proxy for that--a way of becoming your own student. It’s the process of going back and reexamining, recoding, and redoing something that you already know. You keep poking the problem from different angles and solving it in different ways. By doing that, you are not just examining the problem, but examining your assumptions about the problem.

Is this rehearsing in the sense that a musician does it?

Yes, but it’s more than just gaining muscle memory. You’re not just doing the same thing over and over again, because that doesn’t help you. You’re not trying to grind out, say, a binary chop algorithm as quickly as you can. What counts is the thought that goes into it.

What does your own CodeKata practice look like these days?

I’ve just been reading a post by [Ruby blogger] James Edward Gray and am trying to recode his solution to a particular problem-- just because it looks like fun. Also, I am desperately trying again to teach myself enough common LISP so it will actually stick this time.

I especially like to publish books on subjects I’m interested in. And sometimes, I’ll play around with stuff and then come back to the editors and say: “⁠Hey I’d really like to see a book on this subject--just because it’s a fun technology I bumped into somewhere.⁠”⁠ Fundamentally, I suppose, that’s a selfish impulse, but it fits in with our business model. Andy and I have our fingers in every title we publish. We are basically having a whole bunch of fun not knowing how to be publishers.