Ruby on Rails

I've spent about 20 hours in the last week or so learning Ruby and its associated phenom Rails. Besides the sad reminder that three of four books on a computer topic are lightly warmed over manuals, learning it was fun. (For the record, despite great efforts, David A. Black's "Ruby for Rails" is not particularly impressive. Get that man an editor. "Agile Web Development with Rails" by the (oh so humble) author of Rails, David Heinemeier Hansson, was much better.) It's impossible to learn a language without writing an application in it, so I played along with the usual bookstore/recordstore/shoppingcart examples.

Ruby is a good language. It was built by a man with the right ideas in mind. We have easy support for lists, hash tables, anonymous functions, object-orientation, convenient OS access -- all presented in a friendlier syntax than Python and with fewer bizarre exceptions than JavaScript. It's got support for macros, which are what make a lot of Rails possible. For my money, it's still not as clean as a language like Scheme, but people aren't learning Ruby they're interested in the programming language itself.

They're interested in Rails. As well described by its creator, Rails is half of a good web application. Specifically it's the half that was ripped out of his "basecamp" project at 37signals that was framework code. Rails is also a good framework. If you were starting a web application from scratch in ASP.NET or JSP, a Rails programmer would leave you in the dust. The Rails programmer does not need to make any choices: he will use ActiveRecord, the basic object-relational mapper, he will use ActionPack and an explicit Model/View/Controller paradigm for running his web application, and he will leave his project files in a very specific directory structure. By avoiding difficult choices, he is up and running faster. Rails will even create a fully functional basic CRUD application from an object model in less than a minute. You can just sweep in and clean up the pieces.

If I had to write a five screen, ten entity CRUD application today, I'd by very tempted to use Ruby on Rails. Yes, ASP.NET 2.0 has more drag-and-drop functionality and might make something pretty in an hour or two, but that makes a nest of code that's just unmaintainable by professional programmers. Rail code is pretty and concise. Even in a large complex application, a great deal of basic screens are basic CRUD. Here, too, Ruby would shine. When that application starts to have many other components besides basic web navigation and CRUD operations, the Rails advantage would start melting away. You'd be left with a great language, sure, but not so much more compelling than C#2. (Okay, it's far better than C#2, but less exciting than C#3.)

Looking at Rails from the vantage point of our three year old multi-million line web application, I see that it has invented the things we invented: simple O/R mapping, abstracted navigation control, common controls, etc. It gives me several ideas on how we might clean up or augment the framework we built. Ruby is able to express some abstractions more clearly than C#, but that is a function of Ruby, not Rails. I don't see much that it would add to such a large application, and if I were building the app again, I don't think I'd choose Ruby just because of Rails. (In fact, some tools like our SchemaBuilder and Atomics are more sophistcated than anything in the Rails framework, and just about as easy to use.)

Rails needs competition. Another commentator said that it has landed like a bomb on the Ruby community. There are no other realistic O/R mappers competing with ActiveRecord. There's no other way to do web sites without getting laughed at. I find truth in this. It will spur Java and Microsoft to augment their web application frameworks to be more simple and similar (and I suspect Microsoft will be miles ahead on this). It will also be extremely telling to see if commercial component vendors move into the Rails space. It is their energy that keeps ASP.NET so vital. I am not sure Rails will see sustained development of the kind that pushes it into "industry".

I don't see any reason to look at Ruby on Rails for large applications. But if you've got less than 50 tables and a programmer that knows Rails, I'd let him use it. I know Google would.