Developer’s view: Ruby vs. J2EE
Compared to Java, Ruby is a much less verbose, much more flexible language.
Its arrays and hashes provide much of the same functionality split into multiple
different classes in Java (implementations stacks, queues, lists, maps etc.) with
a more comprehensive API. The provided each, map and inject methods allow
the code to be written in much more compact and readable way compared to
the traditional way of wrapping the code inside loops (though the functionality
is overall the same) through passing in Ruby code blocks. Strings in Ruby are
also mutable and provide a very comprehensive API.
These features combined with the way Ruby encourages readability, a more
compact syntax and some more flexible classes allow many tasks to be
performed much more quickly in Ruby than in Java. Having to deal with less
boilerplate code also leads to a much smaller, more maintainable codebase. A
smaller, better maintained codebase in a well maintained project eventually
leads to a more complete test coverage and less wasted time in refactoring, all
leading to a much more productive and fun software development.
The Ruby on Rails framework is probably the most comparable to a usual J2EE
stack. Many of the libraries found in J2EE have a counterpart in one form or
another in Rails, though the Ruby counterparts are often less powerful and
flexible, but do also require less maintaining and less code from a developer to
perform the same task. This comes from the fact that Rails is profoundly more
invested in convention than in configuration, leading to a configuration that
“just works” as long as you don’t stray away from the Rails way. The rails
Hibernate/Persistence counterpart, ActiveRecord, handles Java Bean-like
objects with ease, providing an easy to understand API for more complex
queries, allowing named, perhaps complex, queries through scoping and much
more, all leading to a more organized database access done through a single
model. Scoping the queries via model methods also lead to more self-
explanatory code elsewhere in the application.
In contrast J2EE libraries like Hibernate and Spring that are found a lot in
J2EE applications are highly customizable and configurable but come with an
increased cost in maintainability, partially from maintaining the configuration.
Both Spring and Hibernate provide an extremely flexible structure through
easily replaceable modules. Hibernate i.e. does not limit the path of the objects,
offers multiple ways to specify the objects database representation, has
different validation providers and even offers ways to override some of its
innermost handlers, giving an experienced developer much more control on
how the application flow will be processed. Spring, on the other hand, offers a
lot of different modules for complete customization, providing much of
common functionalities for a web application.
Rails, in addition to actually requiring less code, comes with plenty of handy
and powerful generators that make it extremely easy to follow the set of
conventions and setting up a project quickly from scratch makes building
RESTful applications in MVC architecture with Ruby on Rails is orders of
magnitude faster than with its J2EE counterparts.
For more information: http://extremia.fi/