BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Digging Deeper Into The Myths of Ruby vs. Java

Digging Deeper Into The Myths of Ruby vs. Java

This item in japanese

Bookmarks
Stuart Halloway of Relevance recently wrote a series of blog posts on "Ruby vs. Java Myths". The series was prompted after he switched gears from working on a green field Ruby project back to a well established Java project. During the course of several days Halloway looked at several "myths":

Myth #1: Ruby is suitable for small projects, and Java is better for large, complex projects.

In summary Halloway contends that for small projects factors like the unknown can drastically alter schedule while finding an established library can leave a developer with little actually left to code. These factors are an advantage for Java which has an established community and pool of experienced developers. For large projects Holloway argues that factors like language productivity matter more than libraries swinging the advantage to Ruby. He notes that such logic is backwards to the established wisdom at the moment and explains this by saying:

Ruby is, at present, exceptionally good at one specific kind of small project: database-backed web applications. Ruby on Rails counteracts all of Ruby's small-project disadvantages

Myth #2: Ruby feature X makes code unmaintainable

For this myth the assertion is that Ruby's features make its code more maintainable when used correctly. Maintainable code is defined as:

  1. Understand the overall design of an application or module
  2. Find code you are looking for
  3. Read the code
  4. Make changes to the code
  5. Verify that the changes work

With the following advantages:

    Understand the overall design of an application or module : Neither
    ...In my experience, no language is very helpful here. Good abstractions help. Java and Ruby share many abstractions in common: implementation inheritance, classes, polymorphism, encapsulation, etc...

    Find code you are looking for : Java
    Java wins based on IDE support.

    Read the code : Ruby
    The assertion is that Ruby code is easier to keep DRY and therefore easier to read.

    Make changes to the code : Ruby
    The assertion is that change is easier in a dynamic language.

    Verify that the changes work : Neither
    Both Ruby and Java have good support for unit tests, acceptance tests, continuous integration, etc.

Myth #3: Ruby is too hard

People have argued that Ruby is too hard for the average developer. Halloway argues that programming is hard in general and can't be learned in 21 days despite what the book rack says. Java and Ruby as a result are both hard. He contends that:

...You cannot wish away difficulty by limiting language features...

Myth #4: It is easy to copy Rails' good ideas

it is noted that this myth is tricky since part of it is true. Many of Rails good ideas can be copied to any language. The counter to this however is:

...Other good ideas depend on specific Ruby features. Rails uses open classes to make better, more readable object models. For example, you can say x.blank? instead of StringUtilities.isBlank(x). Individually, such differences do not matter much, but hundreds of them add up to a significant improvement in readability...
Myth #5: It's a zero-sum game

The summary item in the series takes the stance that Ruby wins as a language but Java wins as a platform:

So can't we all just get along? I want to live in a world where language preference does not define a programmer. We'll write code in Ruby, or Scheme, or Scala, or Erlang. And we can all live in harmony on a JVM anywhere.

Steps listed to promote such harmony going forward include contributing to JRuby and managing your next Java application in href="http://www.infoq.com/rake">Rake instead of Ant.

Rate this Article

Adoption
Style

BT