I have read quite a lot about Ruby ("Programming Ruby: The Pragmatic Programmer's Guide" 1st ed. comes with the free one click installer. I bought the 2nd ed at a book store before I saw it all over the web) and am very excited about the purity of its object model. The entire language is object oriented and its own methods may be depricated i.e. copied to .old and extended. It is most definitely not an extension of Perl, although users praise the power of Ruby's text manipulation which was a Perl strength. As a language, it generates excitement for the pure coder because of the elegance it invites into the solution sought. Ruby on Rails, or ROR is attracting many because it's framework is focused on rapid web based business applications, although it need not be limited to web oriented output only.
Business application developers have long relied on various degrees of abstraction to capture business process requirements in applications. All of the CASE tools took either a bottom up - entity-relationship data-driven approach, which worked well for schema generation and RAD tools that relied on the data base to rapidly create prototype applications for user awareness, buy-in and validation; or functional decomposition (James Martin, and others) who diagrammed the business functions, and decomposed them into processes and tasks until the tasks represented very discrete code segments. The input-process-output model will always apply. The top-down folks looked at what was being processed and the flow of data. The bottom up guys looked at what was being gathered, stored and distributed and focused on eliminating redundancy in the underlying structure.
So Rails is more of a bottom-up framework. You generate a data framework from a database, generate controllers for interacting with the data, and then generate the scaffold, or the front-end User Interface. If one adequatly models the data, the relationships imply a great deal about what the process is required to support to maintain the integrity of those relationships. In much the same way as an expert system relies on a rule base and an inference engine to draw conclusions, ROR relies on its specialized methods to apply the inherent business rules captured by the data relationship to create the controller framework.
Rails basically provides a set of code generators. I've used generators and parameter-driven frameworks in pre-web environments. I prefer the flexibility of generators. ROR is especially interesting since it generates HTML on the fly. As more control is desired, you can generate the code that would have been generated, and modify it all you want. Rails does not impose, but nonetheless saves most of the work of manual programming Very simple - applications can almost entirely avoid custom coding: focus on style sheets and graphics and you're done. But you can subsequently generate more specific controllers, views, and models that you can customize.
ROR has provided a significant set of methods to express business rules and the methods to integrated with a UI framework that eliminates much of the drudgery in developing applications, which for me has always been UI.
I have been unexpectedly distracted from ROR due to family events that even encroached on work projects, but I intend to pursue ROR heavily in 1st and 2nd quarter 2006, even as we continue to roll out sites with .Net 2 and good old lampp.
Interest might be further piqued by a visit to
http://rubyforge.org the
http://sourceforge.net equivalent for Ruby open source.
I'd be interested in any correspondence on Ruby.
