In the previous issues, 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 a two-part interview with Hunt's business partner and co-author, Dave Thomas. Among Thomas's six books is Programming Ruby: The Pragmatic Programmers' Guide. Better known as “⁠The Pickaxe book,⁠”⁠ this massive volume is the definitive English-language guide to Ruby. And Thomas himself has become, if not the definitive guide to the language, one Ruby's best known proponents.

Thomas spent his childhood living on both sides of the Atlantic, moving from north-west England to Canada at age five, and picking up (“⁠to my mother's disgust⁠”) an American accent before returning to England. In 1972, Thomas's high school sent a group of bored science students across the road to a technical college, where Thomas got his first taste of programming. He and his classmates punched Basic programs onto paper tape so that they could be sent via dial-up modem to a remote computer. “⁠I fell absolutely in love with this ridiculously arcane system,⁠”⁠ Thomas recalls.

He enrolled in the computer science program at London's Imperial College --only the second year the school offered the degree--where he learned his craft on Digital Equipment Corp. PDP minicomputers, an IBM mainframe, and an old analog computer. Like the paper tapes, Thomas appreciated the older technology. “⁠It was all hands on, and I developed a tactile sense of computers. I've felt ever since then that it is important to know your machine at least a little bit. The notion of programming in the abstract, apart from the hardware, still doesn't do it for me.”

Thomas's professional life is now a juggling act: publisher, author, speaker, and of course, developer. In his spare time he composes music and, when we spoke, had just moved with his family to a new house in Dallas, Texas.

How did you first discover Ruby?

I'm a language nut. I love programming languages―always have. In the 1990s, I was downloading languages off various comp.lang groups on Usenet, which involved downloading dozens of multi-part messages, concatenating them, and then running uudecode on them to get an executable binary. I discarded most of these languages almost immediately because they didn't seem to offer anything new. Others I played with, but they didn't suit me. That's how I came upon Ruby. I downloaded Ruby 1.4 in 1998, three years after it came out in Japan.

Did you know anybody who was using it?

By this time, the language had a following in Japan, but I had never heard of it. The documentation was mostly in Japanese, but there was one English language description that was very usable. I found myself still playing with it at lunchtime, and sometime in the afternoon, I phoned my business partner Andy Hunt and said: I've got this cool language you should try. After he tried it, he agreed.

The timing for us turned out to be perfect. We were just finishing up our book, The Pragmatic Programmer, and we had an idea for another: writing executable specifications. Our idea was that you would write your specifications in code and then use the same code to test what you had done, and possibly to generate the actual source code.

Almost like executable pseudo-code?

Our idea is closer to the agile technique of Behavior Driven Development and the Cucumber tool--but we had in mind something more open than that. As we played around with our ideas, Ruby seemed the perfect language to implement them. But we found that before we could explain our theories, we had to explain Ruby. So we wrote some notes on Ruby as a separate guide, figuring that people could first get familiar with the language before plowing into the main body of the book. As is the way with these things, those notes on Ruby just kind of grew, and eventually, they became the first version of the Pickaxe book.

When did you realize that Ruby might be good for more than just demonstrating your ideas?

Pretty early on, I could see that Ruby was a really nice language. But I wasn't sure if it was usable on decent-sized projects. At that time, I was very much a static typing bigot. I was the kind of programmer who used typedef in C just because I thought it was better for my soul. The problem with that mindset is that when you encounter Ruby, you think: “⁠This can't possibly work, at least on large projects.⁠”⁠ Of course, that didn't much matter back then because people were mostly using Ruby for really small programs. So I thought who cares? This is disposable stuff. I would write my little programs, and they would run, and all would be fine. But the way coding is, you start with a small program and a year later, miraculously, it is now a big program. And to my surprise, as these Ruby programs grew, I didn't encounter the kind of problems I thought I would encounter. I gradually convinced myself that the problems that I thought would come from a lack of static typing just didn't happen. I was surprised, but I was very happy.

Ruby was also one of the first languages to free programmers from the worries over memory management. Up to the beginning of the 1990s, we were all experts on using malloc for allocating block memory. We were accustomed to keeping track of our memory pointers. Ruby was one of the first mainstream languages to free us from all that, and that was absolutely glorious.

Did you view Ruby as a breakthrough language?

Looking back, I don't actually think that's why Ruby stood out. The thing that made Ruby interesting and fun for me is how well it integrated existing stuff--like Ruby's object model, which is very much like Smalltalk's. Matz himself is a language nut, and he produced a Frankenstein of a language that brought stuff in from other places. The genius of Matz is that he took these disparate sources and wove them into something useful. I don't know if you can imagine two more unalike languages than Perl and Smalltalk. Yet somehow, he married them, and their kid came out looking pretty decent. That takes a lot of skill.

That was especially appealing to me because I've always liked Smalltalk. I started dabbling with it in the 1980s, because of its pure object implementation. I loved the stuff people were doing with it. The ThingLab visual programming environment developed at Xerox PARC was absolutely gorgeous. But I never saw Smalltalk as a language I could seriously get behind because I hated the engineering aspects of it. The whole image-based thing to my mind made it very, very hard to do commercial software.

What do you mean?

In Smalltalk, you are putting the program together as it is running. You are adding bits to it and changing stuff, and altering data and code--all within this big bucket of bits, which is called the image. At the end of your day, you save the entire image off the disk, and the next morning you bring the image back in again, and the program is exactly where you left it. If you want someone else to use that program, you share your image with them. People tried to do all sorts of magic version control stuff on top of that, but to my mind the results were always pretty ugly. Don't get me wrong, I think Smalltalk is great for experimentation and for the sheer joy of coding. But how am I going to write a system I can actually give to my customer and then maintain down the road? I never understood how to do that.

What is it that people are seeing in Ruby that is accelerating its adoption?

Ruby lets people get applications out quickly, without compromising on stuff that keeps those applications running in the years that follow. It's always been easy to get applications out fast, but you are then stuck with this pile of junk that you have to maintain going forward. Because of its underlying structure, Ruby allows you to write applications very flexibly, very quickly, but which are still easy to mutate going forward. That means you can start small and grow big, because as you grow, your program doesn't become brittle. I call Ruby the glue that never sets. So as the world changes, it is never going to crack. It will always bend a little bit here and there, and that is a big thing. In practice, the flexibility and the power of Ruby have allowed people to write some pretty clever code. And code like Rails has also encouraged adoption by giving people a starting point when it comes to writing these larger applications.

As a former static type bigot, do you still believe in C++, at least for its performance?

I've never believed in C++. It is the worst of both worlds. It's a remarkably arcane language which I think is impossible to write correctly. It's not that I think Ruby is a universal language by any means. There are some kinds of software I would never dream of writing in it. Of course, there are some kinds of software I would never dream of writing, period.

Like what?

Like software for a pacemaker. I don't know how to do that. Nor do I think that we as an industry know how to do it.

Here's a story. My former boss in England worked for a big development company where they were writing auto-hover software for helicopters. The idea was that if the pilot was having trouble, or they wanted to winch someone up, they could push this button and the helicopter would hover. So they finished writing this software and the client said: “⁠So here is your acceptance test. Your team gets in a helicopter, we go up to 1,000 feet and we push the button and we take our hands off the controls.⁠”⁠ That gave the team a certain focus that it didn't have before.

So imagine I assign you the task of writing pacemaker software. And the acceptance test is that we are going to implant the pacemaker in you. I think there is a world of difference between writing that software on paper and actually having your life depend on it. And I for one would feel very nervous that I didn't think have the skills or tools to produce software that is so life critical. I know companies have developed systems that do it, but I don't know how they do it. And I would certainly never consider Ruby as a target language for that kind of environment.

I think it's useful to think of applications as a spectrum. On one end is the yet-another-Web app. At the other end is control software for pacemakers and helicopters. At some point along this spectrum, you would want to switch from a language like Ruby into something else. But I can't even imagine what you would use.

In between those two extremes are larger projects: maybe critical to the life of the enterprise if not the body. In that sphere, I get the impression that Japanese developers are ahead of us here in the U.S.

I think it depends on what you mean by “⁠ahead.⁠”⁠ In terms of closeness to the core of Ruby, then definitely―most of the key work is being done in Japan. In terms of adoption, though, I think they are still a little behind. I get the impression that business there is a little more conservative than in the U.S. and Europe, and that companies have been slower to embrace Ruby. But I also think that is changing. And, with the recent efforts to standardize Ruby, which is important to companies doing government work, I expect to see a big upsurge in Ruby adoption in Japan. I certainly hope so―it will give me the opportunity to visit more often.

Coming next issue in part 2: Dave Thomas on the mega-growth of The Pickaxe book, forking Ruby, programmer happiness, and why developers, like musicians, should practice, practice, practice.