Ruby vs. Java Myth #4: It is easy to copy Rails' good ideas

Previous Myths:

  1. Project Size
  2. Ruby feature X makes code unmaintainable
  3. Ruby is too hard

Rails enthusiasts and detractors seem to agree on one thing: Rails embodies a lot of good ideas about web development, and other frameworks are changing to be more Rails-like. If my Java web framework of choice is already adopting Rails' good ideas, why should I bother looking at Rails itself?

This myth is a tricky one, because it is partially true. Many of Rails' good ideas can be copied into any language. But some of Rails' good ideas require a language as open as Ruby--so much so that the good ideas in Ruby become bad ideas in other languages. If you copy Rails' good ideas into Java, you will get somewhat less that half of the total value. And if you do not understand Ruby, you will not even know what you are missing. Let's consider some examples.

Some of Rails' good ideas can easily be copied into almost any framework. Take convention over configuration. There is nothing language-specific about this idea, and it is great to see other frameworks moving in this direction.

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.

A more important use of open classes is creating simple, domain-specific languages (DSLs), such as ActiveRecord's declarative relationships and validations:

  class Poet < ActiveRecord::Base
    has_many :poems
    validates_presence_of :name

DSLs often use open classes twice: first to create new declarative "statements" that are legal at class definition time, and second to add new methods depending on the options chosen. You could simulate some of this with Java annotations, but it would take more work. How much more work? Look at the source code for Rails validations side-by-side with Hibernate or Spring validations.

A few of Rails' most controversial ideas are good only in the context of Ruby, and would be bad ideas in Java. For example, many Java web applications have a clean, layered separation of business logic and persistence. This is good idea in Java, in case the application has to change. Rails applications seem to compromise this separation, choosing instead to emphasize simplicity and ease of development. This is a good idea in Ruby, because it is easy enough to add this separation when and only if you need it. (I will say more about this in a subsequent post.)

Finally, we come to the best idea in Rails: Flexible, open languages enable rapid innovation and exploration. What languages will we use to think the big software ideas of 2008?

Get In Touch