arel

Your example is actually a pet peeve of mine. SQL is not at all a nice DSL for working with relational databases programmatically. When you think of it as an API, it exposes one method that takes one gigantic string parameter. API design doesn't get much worse than that. A sane relational database API would let you compose and extend arbitrary queries, which has profound implications for the way you can write your program and abstract away repeated patterns. [Arel](https://github.com/nkallen/arel) has the right idea in terms of API, but a poor implementation (lots of things are not truly composable where they should be). [ScalaQuery](http://www.scalaquery.org/) purports to have the right idea, but I haven't tried it, and it's very Scala-centric.

Although he did specifically call out Ruby on Rails I rather think he meant ActiveRecord the pattern [0] rather than ActiveRecord the implementation [1]. Ruby on Rails' ActiveRecord has come a long way and actually implements proper relational algebra through Arel [2] now. [0] http://martinfowler.com/eaaCatalog/activeRecord.html [1] http://ar.rubyonrails.org/classes/ActiveRecord/Base.html [2] https://github.com/nkallen/arel

I think a lot of this will improve with Rails 3's new query syntax. It looks a lot like LINQ for .NET. Yeah, a lot of times you're using the same keywords you might use in SQL, but the new chainable extensions are really nice for building up queries and reusing common chunks (either in LINQ or in Rails 3) I should note that this new relational syntax is provided by a library called Arel (http://github.com/nkallen/arel)