This post originated from an RSS feed registered with Ruby Buzz by David Heinemeier Hansson. Original Post: Why Rails looks so good (and why it matters) Feed Title: Loud Thinking Feed URL: http://feeds.feedburner.com/LoudThinking Feed Description: All about the full-stack, web-framework Rails for Ruby and on putting it to good effect with Basecamp Latest Ruby Buzz Posts Latest Ruby Buzz Posts by David Heinemeier Hansson Latest Posts From Loud Thinking

Bill Katz is a fiction author and technologist currently busy on his new venture Writertopia. He's also very interested in the beauty of Ruby on Rails and how it relates to Paul Graham's love for LISP:

Graham talks about bottom-up design, changing the language to suit the problem. It suggests one reason why Rails looks so good compared to other web frameworks: Rails looks like souped-up Ruby and not just a bunch of classes, procedure calls, and bolted-on code.

"In Lisp, you don't just write your program down toward the language, you also build the language up toward your program," Graham wrote. "Language and program evolve together... In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient." That's a pretty good description from 1993 on Rails development and points to a not-so-subtle difference between the web frameworks.

This is with out a doubt one of the Ruby features that excites me the most. The ability to evolve your own dialect of the language to fit the domain. The purity and beauty in code like the following is intensely satisfying (this is not pseudo code, it's fully executable without a precompiling code generation phase):

  class Project < ActiveRecord::Base
    belongs_to              :portfolio
    has_one                 :project_manager
    has_many                :milestones
    has_and_belongs_to_many :categories
 
    validates_presence_of   :name, :description
    validates_acceptance_of :non_disclosure_agreement
    validates_uniqueness_of :key
  end

Which is also why calling glue kits like Trails a clone of Rails in Java just makes no sense (and exposes the sender of such a statement as uninformed at best). Replicating a single feature of Rails, such as Trails does with Scaffolding, does not a clone make. Not only is it a pick on one of the most shallow features of Rails, but it also possesses none of the elegance. Katz addresses this with:

When answering the question "Could Rails be built without Ruby?", I think you have to address not only the functionality but the aesthetics as well. It's more than the simple lines-of-code metric. It's whether you've built a language up towards a Rails language that solves problems common in web development. As Graham points out, you could build Rails out of any language that's Turing-equivalent; the real question is in your quest to duplicate the aesthetics, whether you'd wind up doing a back-door implementation of a Ruby interpreter in the process.

When Bill Katz calls Rails "...a work of art in progress", I can definitely imagine Serious Developers tuning out: "Code is not supposed to be artistic, just functional". To me that's a terribly depressing statement. Code that can be both "art" (as defined by striving for elegance and readability as primary motivation factors) and functional is what makes programming interesting to me.

Oliver Steele from Lazlo touched on many of the same issues.