There are good and bad abstractions. Speaking purely in terms of computational efficiency, a good abstraction gives an optimizer more information about what you're trying to do. Optimization is basically about reconginzing that there are multiple ways of compling a given bit of code, and the Programmer shouldn't have to worry about what the best way is.
Speaking in terms of programmer efficiency, a good abstraction will allow the most work done with the least amount of code. A good language will aim for the easiest way to program something to also be the most computationally efficient. For instance, a Perl programmer who has a large ammount of data indexed by a string will often automatically reach for a hash. Which is great, because a hash is likely the most computationally efficient way, too.
Now, Class::DBI gets tripped up because it can't get enough information to create the SQL. Consider this Law-of-Demeter-breaking snippet for getting through a few joined tables:
my $table3 = $table1->table2->table3;
If we were writing raw SQL, we could get this in a single SQL statement with a three-table join (which is hairy, but possible). But because Class::DBI has to fetch each table individually, a lot more SQL would be needed (I'd have to dig through the source to know just how much, but it's definately more than a hand-optimized version).
So this is a case where the abstraction makes it easy on the programmer, but hard on the computer. Maybe that's OK, and maybe it isn't. It all depends.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
|