As I stated last November when I reviewed his previous book, I am a fan of Bruce Tate. He writes well and delivers useful content.

His newest book is From Java To Ruby, published by The Pragmatic Bookshelf. It is a quick read (150 pages) and the price is right (about $19 from amazon.com). There are some rough spots where I wish he had provided more details to backup some of his somewhat glib statements, but in general I thought the book was worthwhile.

It is important to note what this book is not. It is not intended as a guide to learning the Ruby language or its very popular framework, Ruby On Rails (RoR). It is instead for software development managers and consultants that want guidance on how to introduce Ruby into an organization. Tate's central thesis is that Ruby can reduce development pain in certain situations. The most important piece of advice in the book is on page 17:

To be successful, you need to understand the pain in your organization and interpret it. You need to know where the pain is the most acute. Most projects don't fail for technical reasons. If you can't solve your communication problems, if you can't control scope creep, or if you can't tell what the customer actually wants, the choice of programming language is not going to matter to you. It's simply not high enough in the hierarchy of pain. Put this book down, and pick up another one. Ruby won't help; it will only introduce more risk.

In other words, if Java is not your problem, then moving away from it is not going to solve your problem. That sounds like common sense to me, but as John Reynolds recently reminded us, "common sense is not very common." Several chapters in this book contain good common sense ideas for doing project management, handling risks, etc. A good deal of the rest of the book explains why Java is broken and why Ruby is the solution.

Or I should say, for which type of applications he thinks Java is broken and Ruby is the solution. Tate is careful to point out Java's strengths as well as weaknesses and he describes situations where Java is the correct choice instead of Ruby. He also gives quite a bit space to the JRuby project in chapter 6, and provides some interesting ideas about a future environment that combines the respective strengths of Ruby and Java.

As he did in Beyond Java, in this new book he is focused on web-based applications that run on top of a relational database. This is from page 7: "The intended niche of Ruby on Rails is database-backed Internet applications. This is clearly the most important application niche, and we'll focus on this space within this book..."

Tate feels very strongly, however, that RoR is not Ruby's only advantage. In his view, dynamically typed languages like Ruby will always be more productive than statically typed languages such as Java. In addition, he is not too fond of Java's C++ like syntax and the fact that the primitive types are not objects. I am guessing that the auto-boxing feature added in Java5 was in his view too little, too late.

The guesses that I had to make were one of the disappointments I encountered while reading the book. While he is careful in some sections to back up his statements with detailed explanations and data, in other places he just tosses in comments such as (from page 26): "EJB has gotten a little better, but it's still an albatross..." I am assuming he is refering to EJB3, but he does not say. More frustrating, though, is: what specifically is it that he finds albatross-like about EJB3?

The other disappointment was the topics that were left unmentioned. One of the central ideas behind the book is to talk about the risks involved in migrating to Ruby. And yet, these topics did not get covered:

• Migrating from one version of RoR to another. He talks about how easy it is to extend RoR (and points out you would never attempt the same amount of extension of something like Hibernate). But how do I move my application from RoR version X.Y to version X.Z? How painful will that be?
• Once I move my application into production, how easy is it to troubleshoot problems and monitor performance? This gets only a slight mention.
• No mention of the level of support for things like internationalization and accessibility, two areas where Java does a pretty good job.
• If I need to host a Ruby application outside my own data center, how easy is it to get good hosting, and at what cost?

The most important topic that did not get covered, though, was what I refer to as "the anti-tipping point." Tate recognizes that Ruby could end up being the next Smalltalk, which he describes as not necessarily a bad thing. He thinks it much more likely that Ruby will instead be a huge mainstream success. What he did not provide, and what risk-averse development managers could use, is a description of the signs to watch for that indicate that he's wrong and that Ruby is in fact becoming the next Smalltalk. That way a reader of his book would be better able to react as the future unfolds.