This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: yes, abstractions leak - some more than others
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
One of the Java Bloggers (Daniel Steinberg) talks about leaky abstractions. Joel on Software wrote on this last year (and why doesn't this guy link to it, since he mentions it?) - then he lets loose with this:
To make code more performant, you generally have to make it less readable. Readability often involves introducing abstractions. You don't talk directly to your data base, you use JDBC. You don't follow pointers to find the next element in a collection, you ask the corresponding Iterator to return next(). The problem with this, according to Joel Spolsky, is that all abstractions leak. Today in Java Today Craig Castelaz discusses this balance in "Living with Leaks". Craig looks at Spolsky's Law of Leaky Abstractions and Keppler's continuum of abstractions that predates Spolsky's work by a decade.
Hmm. Maybe It's that I use better tools, but I find just the opposite. cleaning code up and making the intentions clearer typically lead me to faster code. I consider this whole idea of "nasty code is faster" to be a hoary old chestnut that needs retiring, fast. Referencing the Cringely article (and why doesn't he link to it?) shows a high level of cluelessness. If he thinks refactoring is useless, he shouldn't be writing code, period.