When Ruby inventor Matsumoto “⁠Matz⁠”⁠ Yukihiro talks to programmers, he sometimes mentions two books: From Java To Ruby: Things Every Manager Should Know by Bruce Tate and The Passionate Programmer by Chad Fowler. If they’re good enough for Matz’s bookshelf, they have certainly earned a place here. Over the next issues, I’ll be interviewing Tate and Fowler, as well as their publishers, Andy Hunt and Dave Thomas, who run The Pragmatic Programmer and are co-authors of the definitive English-language guide to Ruby.

Bruce Tate grew up in Memphis, majoring in computer science and mathematics at Mississippi State University. He left IBM after a 13-year stint and forged a second career as an independent consult and author. His books have all touched on a subject of importance to every working developer: how to deal transitions--technical, managerial, personal. The first was called Bitter Java, which tells you something about his ambivalent relationship with the language. His 2006 book, From Java to Ruby, tells you where he headed next. Tate’s most recent book, Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages, was published in November 2010.

Tate isn’t dogmatic about technologies, but he thinks your career will go better if you are open to new things. An experienced kayaker, Tate says that sometimes, the only thing you can do in a crisis is “⁠paddle like hell.”

You write not just about moving from Java to Ruby, but about the challenges of any technology transition.

That’s true. There’s the transition, for example, between an interpreted and a compiled language. I loved Basic. It’s a wise language, and most people don’t give it respect. When I went to college and started picking up C, a part of me died. Working with Basic is very interactive. It gives you the same kinds of opportunities to explore as Smalltalk and Lisp.

It sounds as if you’re talking about what Matz refers to as programmer happiness.

Matz has tried to optimize a language for the programmer instead of the computer--and that’s absolutely the way to go. For most of the problems that we need to solve, the computer doesn’t need to be any faster, but the programmer does. Software projects fail because we can’t state things simply enough. That inability leads to more complexities, which leads to more time pressures--and it basically snowballs from there.

After I wrote Seven Languages in Seven Weeks, I began noticing that while many of the people I respect were moving toward functional languages, some were staying with Ruby. I think the reason is that Ruby has such an expressive syntax. To me, that is the most important problem that I am solving right now―how do I communicate my intention to my customer, to the computer, and to myself? I’m forming more and more complex ideas, and Ruby allows me to craft those ideas using larger and larger building blocks with a beautiful syntax that reads like I think.

You established yourself as a Java developer, but you’ve long had mixed feelings about the language. After all, one of your earliest books is called Bitter Java.

That book kicked off a firestorm over what’s wrong with Java and it kick-started my consulting career, as well. My book Better, Faster, Lighter Java won a [Dr. Dobbs] Jolt award because it argued that we were putting all our energy into the frameworks, instead of solving the business problems. At the time, I was working with COBOL developers who wanted to transition to Java. I was pretty confident we could do it. We just needed to teach them this object-oriented thing and then this Java thing, which would require them to learn this Apache Struts thing. Then we just layer on this database thing and this hibernate layer. Every time I listed another course or requirement, the customer sank down further in his seat.

So I began to question both my career choices and my assumptions. As a developer, I knew how to do one thing: build light-weight Java applications. And I didn’t believe that the particular language you used made much of a difference. I believed that if you forged a good relationship with your customer and picked a reasonable language, everything else would fall in line.

But then I started asking Dave Thomas some questions about Ruby. And feeling threatened, I was a bit hostile in my tone. Finally Dave, who is the consummate gentleman, got as close to flustered as I’ve ever seen him. He basically said: shut up, go away, and come back when you’ve done something non-trivial in Ruby. As it turned out, my business partner was thinking the same thing. While I was out of town for a few days, he wrote an entire project, something we had been working on for months, in Rails.

I wrote about that experience in Beyond Java, and people assumed that Bruce Tate was saying that Java is dead. But I wasn’t saying that at all. I was saying: pick your eyes up, look around, and see what else is going on out there. New languages start every 10 years or so, and if you don’t understand their implications, you are going to be obsolete.

In this case, you were questioning not just Java, but Java’s lineage.

We have essentially been doing application development using languages based on C/C++ for about 30 years. And that’s crazy. The whole Java syntax is based around a language originally created to build an operating system. I think that languages have a shelf life. The Java Virtual Machine is fantastic, and there are some interesting things happening there now. But for applications development, maybe we should never have been using Java in the first place.

Matz said that Ruby has been more readily accepted in Japan for larger projects. Is the U.S. starting to follow that lead?

In the United States, most Ruby developers are being snapped up by the small business and startup communities. But as an industry, we are starting to think, not just about Ruby, but other emerging languages. In microprocessor design, the practice of layering multiple chips onto stacks basically punts the concurrency problem over to software developers. I’m not sure that object-oriented languages in general are the best way to handle those problems. Functional languages will play an increasingly large role, and to Matz’s credit, he’s done a great job of giving some of those paradigms to Ruby developers.

You said Java had gotten too complex in terms of the number of frameworks. Is Ruby in danger of the same thing?

It is somewhat inevitable for all languages, though I think you can delay it. One of the interesting things that happened to the Java family of frameworks is that they have extended Java in ways that aren’t characteristic of statically typed object-oriented languages. Extensions like byte code enhancement and aspect-oriented programming have quietly, but fundamentally, changed Java, making it more like a “⁠Java++⁠”. But inevitably, as languages and frameworks grow, they will bloat. People want to do interesting things with them, and eventually, complexity ensues to the point of collapse. That was definitely true of Java, it will be true of Ruby, and it will eventually be true of the functional languages if they are in fact the next step in the evolution.

You argue that the transition from one language to another is as much a management challenge as a technical one.

In the United States, we’ve had a long-standing practice of saying that if we want a more powerful development team, we should put more developers on the job. But the opposite is often true. As you add more developers to a job, each developer becomes less and less productive. What you want to do is find ways to give developers more leverage. That means either educating them on new tools and processes or getting more educated developers―either approach will work. You do that, and then you get out of their way.

You are a kayaker. Do you see any parallels between the sport and your work?

In Bitter Java, I compared the crashes and burns you get with programming problems to what happens when extreme sports activities go bad. With every kind of extreme sport, there is an element of planning and an element of organization. Teamwork is required: you can’t kayak a dangerous river alone.

What about community? Is that also a Ruby attribute?

Matz and his community have been all about respect and kindness and fun. There is that acronym, MINSWAN, “⁠Matz is nice so we are nice.⁠”⁠ That’s part of the greatness of Ruby: the love really comes through the code and the structure of the language.

Sometimes, though, that’s not the best way to break through and be successful. With Ruby on Rails, David Heinemeier Hansson brought forth a more a competitive culture. He built a framework where the configuration was simple and clean, with good documentation. He built a beautiful framework that keeps start-up costs low and can be easily extended. But looking back, I think his marketing of Rails was a bit combative. David gave a giant poke in the eye to the Java community. He wanted to starkly contrast the Java enterprise community with the Ruby on Rails framework. In the formative years of Rails, that was a very aggressive marketing strategy, and it was quite effective. But I can’t help but think we lost something along the way. In some ways, it diminished the culture, though that was part of the cost of Ruby growing up. Even now, you can still see the schism. There’s a dramatic contrast between the Ruby community and the Rails community.

Do you think the Ruby community still reflects Matz’s vision?

Yes. I’d like to thank Matz, not only for his work in the field but for his value as a person. The love and passion with which he has lived his life have definitely shown up in his code and in the community that is has grown up around it. That has been tremendously valuable for me. Matz is always talking about having fun, but I think it goes beyond that. He has built a community and a philosophy about living with kindness and excellence. Great programmers and great people of all kinds can appreciate that.