Skip to main content

From Java to Ruby

Posted by gsporar on July 16, 2006 at 5:24 PM PDT

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
). 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."
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
, 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.