Re: Joel’s law of leaky abstractions

I like Joel Spolsky’s The Law of Leaky Abstractions – particularly his excellent illustrations of the word abstraction. I also like his argumentation about how abstractions are more likely to “leak” the less trivial they are. But I don’t know if I would like to call it a law.

It certainly is the case that many high-level abstractions leak and cause difficult bugs, but to use the word “law” signals that it’s should be virtually impossible to create leak-proof high-level abstractions. Of course, on a certain level, it definitely is impossible – there’s always something that can go wrong – but what’s interesting is abstractions that for the most time are leak-free; that have a low enough mean-time between leaks (MTBL).

To me it seems to have much to do with abstractions communicating errors to their users in as meaningful way as possible. No errors should just be let through, but instead wrapped with either more information added to it, or completely rephrased but keeping the original error details.

It also about powerful abstractions; powerful metaphors that not only serve to explain their intent but also their errors. Joel’s example of the ASP.NET abstraction for hyperlinks, that breaks if the user has JavaScript turned off, is to me a case of building an abstraction upon a fragile inferior abstraction, so to speak. If the underlying abstraction is broken (JavaScript turned off), the above abstraction is completely useless. The error “JavaScript turned off” simply doesn’t allow for easy rephrasing on the higher level, which signals that it was a bad move to base it on hyperlinks and JavaScript.

When I read this I came to think about Charles Simonyi’s intentional programming – which I can’t say I have understood fully yet, but it perhaps addresses this. See the Google search results for “intentional programming” on my weblog.