Bruce Tate, a (former?) Java evangelist, became an advocate for Ruby on Rails and caused a large, passionate thread on TSS about RoR vs. Java (http://www.theserverside.com/news/thread.tss?thread_id=37121 ). Of all the posts, I was struck by one of Bruce's that describes why RoR is different:
> .... For at least one class of applications, web-based apps on a > relational database where you control your own schema, you'd be crazy > not to consider Rails. It's just too productive. I didn't understand > either until I used the framework in anger. What's different? > > - Rapid turnaround time. Save and reload. That's it. Very compelling. > > - Starting point. You start with basically a working CRUD app per > table. Windows to do list, show, edit, delete, new. Sure, you'll > rewrite some, but you can put something in front of your customer > instantly. That's compelling. To get all of this, you can either do a > one-time code generation pass (it's not that much code in Rails), or > you can do a scaffold :person command. > > - Reduced configuration. For us it was a 10-1 reduction. I think > that's fairly typical. More for some extreme struts apps, less if you > don't count annotations (but I think we're often making a big mistake > with annotations.) > > - Better mapping strategy for the Rails problem set. Here's an active > record class, that maps a Person class to a table called people, and > belongs to a department: > > class Person < ActiveRecord::Base > belongs_to :department > end > > End of story. You want syntax? That's syntax. You get a property for > every column in the database, custom finders like find_by_last_name, > and other goodies to manage the belongs_to relationship. No repetition > of column names. No code generation. > > - Much better AJAX, and cleaner view technology. > As to quick and dirty, I used Java because it was clean, although > slow. I didn't use PHP or Perl because I think they are quick and > dirty. I think Ruby on Rails is quick and clean. The interesting thing is that a lot of this stuff could easily be supported in Java web frameworks, and Beehive in particular is well-suited (e.g., with its single-annotated-file model). DISCLAIMER: I am *not* the first person to make the statement above... in fact, I think I've heard basically the exact same thing from Daryl. I'm just being struck by it. But... is this something that can help us define a mission statement for the next set of Beehive features? We don't need to *be* Rails, but we could certainly learn from it. Rich
