Related link: http://www.onlamp.com/pub/a/onlamp/2005/10/13/what_is_rails.html?page=last#threa…
In comments on Curt Hibbs’s What is Ruby on Rails?, he and Aaron Trevena, maintainer of Perl’s similar Maypole project have debated whether Ruby or Rails are doing anything particularly new.
For people who’ve only ever seen complex “enterprise-class” frameworks and libraries and designs as usable, certainly watching any of the Rails movies might give some evidence that being able to solve the 95% of all possible web programming problems that don’t need huge application servers and complex transactional and messaging systems with a fraction of the effort and perhaps fewer lines of code in general than the complex system requires lines of XML in configuration files is a good thing.
Of course, anyone using a decent set of libraries in Perl, Python, Ruby, or PHP probably already knew this.
Ruby does bring certain advantages; I much prefer the ActiveRecord syntax and introspection over that of Perl’s Class::DBI, but they’re both fantastically useful. They’re equivalent enough that neither offers an order-of-magnitude improvement over the other.
Where something like Python’s Django might invent and polish a new idea, the amount of time and work necessary to do something similar in Perl or Ruby isn’t large either. I don’t have enough practical experience with PHP 5 to judge there, but I’m sure it’s also flexible and dynamic enough to work.
In my mind, the issue isn’t “Ruby on Rails is more flexible and capable than standard J2EE or .NET for any project under a (very high) threshold of complexity”. The real point is that the simplicity, flexibility, and abstraction possibilities offered by dynamic languages and well-designed libraries — as well as a talent for exploiting radical simplicity, extracting commonalities from actual working code, and knowing when too much flexibility makes you less agile — offer a huge advantage over languages and libraries and frameworks and platforms that assume you need a lot of hand-holding to solve a really hard problem.
Yes, Ruby on Rails does what it does very well. It’s not the only thing that does, though. I wonder perhaps if some of the buzz and glow is that it’s new and shiny (in comparison), so that people haven’t already formed their own opinions about it, as they may have with Perl (oh, you can’t write readable and maintainable code), Python (all the fun of the Lisp community without half the things that make Lisp special), and PHP (a language that needs to grow up).
Fortunately, a lot of smart people already understand this. It would be nice to have the right debate, though.
Am I wrong? Is it really Ruby and Rails, or is it the dynamicism, flexibility, and better opportunitites for abstraction of dynamic languages that provide so much of the benefit?
One rails advantage
chromes, there is one Rails advantage over Catalyst: a bit of simplicity. Catalyst shows its components to you right on its home page (ick!), whereas Rails hides them, appearing monolithic.
Please don't ask me to choose a templating module -- I don't want to! Pick one and let me change it if need be (the Rails principle of convention over configuration). I realize this is just the Catalyst web page but this is, in part, a marketing struggle.
As a longtime Perl-head, I would like to see a Catalyst / Maypole knockoff dumbed down (hiding its innards), appearing more monolithic, which would inspire lots of books and articles for all levels of users. (Minor niggle: as far as a name goes, Catalyst is hard to say, and Maypole just sounds dirty).
Perl-heads are unlikely to leave CPAN behind just for Rails. Can there be any doubt about this? It's much easier to "absorb" the benefits of Rails into a Perl-based project, than to absorb CPAN into Ruby (Gems is fine but not as extensive as CPAN).
-----
On a related note: The recent slim O'Reilly book "Beyond Java" had lots nice to say about Ruby but it's evident the author had little knowledge of Perl 6 -- that would have changed the whole vibe of his book.
How could a best-selling O'Reilly author writing about the future of dynamic languages (be allowed to) know so little about Perl 6? A good read, though.
One rails advantage
The point about too much choice is a good one. Though there are plenty of highly-opinionated Perl hackers who love Mason and hate TT (or HTML::Template, or Petal, or whatever), it's easy to believe that the need to research all of the alternatives and choose one before even getting "Hello, World!" running kills a lot of the easy momentum that Catalyst could have.
Perhaps the new Catalyst::Enzyme will help.
(I don't know why people don't know much about Perl 6, other than the perception that it's taking too long and won't be amazingly amazing.)