Why?…that’s the feeling I have after reading Rails for Java Developers.
The book (given 4 1/2 stars by its reader-reviewers) is fine and nicely illustrates the Java way vs. the Rails way, but as to the Rails way itself…hmmm.
Typically the authors introduce a problen with a Java example, followed by an equivalent piece of Rails code and announce “Look, ma: no XML!” or “That was much less to type, wasn’t it children….” Time and again however, the discussion moves onto a disclaimer:
The place where Rail’s default logging falls far short of log4j is in supporting a variety of appenders
If you need these [client-side validation with Javascript/internationalization] features in your Rails application, you will have to find a plugin or roll your own.
The Ruby world does not have anything as comprehensive as CruiseControl.
Ruby IDEs do not offer nearly the level of code completion and refactoring that the best Java IDEs do.
Because the Java platform includes a virtual machine specification with documented profiling hooks, it beats Ruby profiling not only in practise but in concept
ActiveRecord provides no support for distributed transactions, and when we miss them, we miss them acutely. Rails is currently unsuitable for systems that must enforce transactional semantics across different databases. But chin up! The JRuby team ( http://www.jruby.org) is working to make JRuby on Rails viable. Once it is, we will have access to Java’s transaction APIs.
There seems to be a pattern here…
[edit: I guess I didn’t make myself clear here. I was struck by the fact that there always seems to be a disclaimer. Open any page, follow the topic and before the coverage is complete you will see this sort of disclaimer…. So: why?]
My impression is that Ruby is really going after the low-hanging fruit, not that there is anything wrong with that.
As far as I can see, however, the bushes (at both the low-hanging and tip of the tree levels) are pretty well picked over by the myriad of PHP, Perl, Python and Java frameworks out there (and let’s not forget Grails), and I find myself wondering whether Ruby/Rails really has the ‘puff’ to go to the next level. Leaving aside the existence of JRuby for the moment, this pretty much means reimplementing the whole IT infrastructure: transaction management, messaging, view/templating/conversation technologies, testing, etc., etc.. Everything.
Yes, redoing everything for Ruby/Rails probably is fun (especially if you missed or have a hankering to re-live the dot-com bubble era…) and may even reduce the amount of keyboard pounding that Joe Rails Programmer has to do, but is this effort really valuable?
Perhaps I am too old to really appreciate the subtleties here. After all, as the old adage goes: if you can’t change the people, change the people.
