Fog Creek Software
Discussion Board




Leaky Abstractions & Meta Object Protocol

Remembered reading about the law of leaky abstractions sometime back @ http://www.joelonsoftware.com/articles/LeakyAbstractions.html and was watching this presentation at http://murl.microsoft.com/LectureDetails.asp?259 on Meta Object Protocol, when I realized that they are speaking about the exact same problem!

Wonder why the Meta Object Protocol has not becomre prominent... Too complicated.. ?

satya
Tuesday, March 04, 2003

I don't get this "Leaky abstractions" thing...
Abstractions are defined, AFAIK, to be simplified versions of the object, where all irrelevant stuff is discarded.

What Joels article talks about is how hard it is to implement something from an abstract desciption, or from a simple list of wishes.

So, saying that abstractions are leaky is like saying "circles are not rectangular". We know that, and we actually want and expect it to be that way.

What Joel calls leakiness is a basic property of an abstraction - you discarded the irrelevant stuff, and boom! You got an abstraction!

So if Joels abstraction seems to leak, it's either because
- He discarded something that was not irrelevant, and thus his abstraction was not an abstraction after all, and therefore he cannot conclude that abstractions are leaky.
- He expected his implementation of the abstraction to have the same properties as his abstraction, but it didn't (of course! The abstraction covers only the important stuff, the implementation has to cover everything!). So something is wrong with his implementation, but his abstraction still stands unleaky.

Or am I missing something?

Martin
Wednesday, March 05, 2003

Leaky abstractions to me are ones that sound like a good abstraction on the surface but which are actually flawed representations of the actual thing they represent.

Some people know this and adjust behaviour accordingly, but I'm sure that everyone knows at least one person who thinks that understanding an abstraction of a problem is the same as understanding a problem. Those people are going to cause trouble.

Robert Moir
Wednesday, March 05, 2003

I just reread the article.  His Law of Leaky Abstractions:
"All non-trivial abstractions, to some degree, are leaky."

One way to restate this is that all of our important communications and beliefs are simplifications of reality that can lead us astray if taken too literally.  Another is that knowledge is fractal; look closely enough and notice many tangents to research.

I'm ordering the video lecturer's book, but as I understand it, the metaobject protocol is actually in somewhat common use.  In Java, there's "reflection" which gives metaobjects for an object's details like methods, class hierarchy, etc.  Python even gives you access to doc strings.  So unless I understand badly, people do use metaobjects every so often.

It's not very common in Java since Java tends to discourage programmers from doing cool things at runtime, but still it can be a clean way of creating classes dynamically.

BTW, you reminded me of the old worse-is-better article.  [ http://www.jwz.org/doc/worse-is-better.html ]  It's hard to make good abstractions (can you make a good contradiction-free religion?) but worth it in the end.

Tj
Wednesday, March 05, 2003

Actually if you look view the presentation above, Gregor Kiczales deals with exactly this problem. How to expose some internal nature of the abstraction (what he calls a mapping dilema) so that an user of the abstraction can supply an alternate algorithm for the cases where the current assumption does not make sense.

One example he gives is for the Oracle implementation, where he says (based on his discussions) that about 35% of the code is actually a reimplementation of the OS memory scheduling algorithm because some db memory needs to be LRU while others need to be MRU!


The presentation is worth watching! ;-)

satya
Wednesday, March 05, 2003

Definitely a good presentation!

What I get from it is that leaky abstrations are caused by hidden implementation decisions that are made affect the behaviour of the class/object in certain ways.

That is the nature of abstrations and we have all ran into them. Currently to overcome these problems we usually have to do major workarounds

Gregor is saying we have to find a way to expose those hidden implementation details and let the client choose which implementation to use.

There are huge problems to overcome but I think it is something to think about the next time you are creating classes.

DJ
Wednesday, March 05, 2003

*  Recent Topics

*  Fog Creek Home