Link Details

The underlying premise of the article (as I understood it) is that hiding SQL from developers is the underlying value to ORM tools and that that is a bad thing. I disagree with that assessment of the purpose of ORM tools, but along with the comments, which point out that ORMs also handle the crap with wrapping result sets into objects and dealing with JDBC try catch blocks, it was an interesting read.
,

Hiding SQL isn't the purpose, but recasting the SQL syntax in a way that is natural in the language the ORM is implemented in has advantages. I agree with planetmdc that it's not the primary purpose of ORM's though. To me, the primary purpose of an ORM is to make it easier to persist model objects.

Sometimes that means complex translation between the relational model and your object model, sometimes you can get away with Active Record (the pattern or the ORM, take your pick) style straight mappings from the schema to the object model - there are many valid approaches that are appropriate for different uses. The more distant the object model becomes from the relational model the data is stored in, the more important hiding the SQL (the concepts, not only the syntax) becomes because the disconnect between the two grows larger. For ORM's using the Active Record pattern, wrapping the syntax is nice, but wrapping the semantics is less important since the disconnect is fairly small (relations between tables, joins and groups will not necessarily fit naturally in the object model, but it's often close enough that it's not too painful to deal with, and it can be wrapped neatly in the model relatively esily most of the time).

If we get more ORM's that move "up the value chain" to more complex ORM patterns, it'll be interesting to see how they handle the increased disconnect without lots of manual work to wrap SQL like (semantics or syntax) constructs.