Hacker News Reader

Comment by ntoshev | Hacker News Reader

I believe transparent abstractions are a big part of what made Rails successful: e.g. you have a primitive for an input box in a form, but you can pass through arbitrary attributes to the generated HTML.

View on HN

I think the form helpers in Rails are handy shortcuts, but I don't know if I'd call them abstractions. Abstractions are tools for generalizing, but Rails helpers only produce HTML output. Only if you could re-use the same helpers to produce a variety of different types of markup would I call them an abstraction (and that would probably make it necessary to make the abstraction less transparent).

A better example of a true abstraction in Rails is ActiveRecord, which I think you'll agree is bit less transparent.

ActiveRecord allows you to query the database directly using execute() or use a query to populate ActiveRecord objects with find_by_sql().

execute() returns the result in whatever form the underlying database driver uses. I think that's about as transparent an abstraction you could ask for. You can completely ignore ActiveRecord's abstractions.

find_by_sql() returns an array of ActiveRecord objects.

thats not transparent that's discardable. Transparent would be knowing what happens when you don't use execute() or find_by_sql(). Just because a library allows you to avoid using it in the way it was intended to be used the most doesn't make it transparent. That just means it realizes that sometimes you have to discard the libraries features and do something else.

exactly. it's nice that AR makes it easy to go down a layer, but then you're no longer abstracting away the database.

edit: to be fair, I was less than precise in my earlier post when I said that ActiveRecord wasn't totally transparent. I was specifically referring to AR as an abstraction that can be used identically across various different databases.

Reply on news.ycombinator.com