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.
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.
