In my (mostly former) world of programming there is a fetish for “abstraction”.  You can see the word abstraction everywhere.  Operating systems have HALs: Hardware Abstraction Layers.  There’s Abstract Data Types.  In extreme cases you have advocates of languages like the Haskell language who worship abstraction to the point that they talk about Monads and Functors and Monoids and Arrows and a whole bunch of capitalized abstractions, structures that are so abstract most programmers have a difficult time seeing how they’re even remotely usable.

But here’s the thing.  Way back in 2002, a fairly famous programmer named Joel Spolsky typed an article called The Law of Leaky Abstractions.  In it he gave the now-famous (in some circles infamous) “law”: All non-trivial abstractions, to some degree, are leaky.  In his blog he goes into several examples that require a bit of technical sophistication to understand.  I’m going to use a different one because it’s the one that bit me hard back when I was young and foolish (instead of old and senile).

I want to address the “transparent remote procedure call”, one of the Holy Grails of software engineering in the ’90s.  The reasoning behind them went thus: a “local procedure call” (an order to tell the computer to do something in the same program) and a “remote procedure call” (an order to tell the computer to do something that’s in another program, perhaps even on another machine half the world away) are in their essence the same thing.  You have a name: call it “add”.  You have parameters: say 2 and 7.  You have a return value: in this case 9 (the result of adding 2 and 7).  This is exactly the same thing whether your “add” routine is in the same program that’s currently running, in a different program on the same machine, or even in a different machine altogether.  So… obviously they should be addressed the same way.  We should “abstract away” the differences of platform and carrier such that the programmer need not worry about the differences in the three (and several more) modes of access.

This sounded really good in theory, and programmers, being the geniuses at solving the wrong problem that they are, quickly came up with a wide variety of methods to accomplish this noble goal.  And it was an unmitigated disaster.

See, it turns out that while at a superficial level a remote procedure call and a local procedure call are the same thing, it’s the details that are the devil.  A remote procedure call on the same machine could be hundreds to thousands of times slower than a local procedure call.  A remote procedure call to a different machine is instead tens of thousands of times to millions of times (and on to infinity!) slower.  The abstraction of a general procedure call has leaked and leaked really badly.  You need to know if you’re doing local or remote calls or your software was going to be really, really, really slow.  (You know, like much software in the ’90s was….)  Also, your remote procedure calls can fail in ways that a local call cannot possibly fail short of your computer being on fire.  If you don’t know you’re doing remote calls your software is going to be really, really, really buggy.  (You know, like it was in the ’90s….)  The abstraction has actually damaged your software and your understanding of its working.

So what does this have to do with the price of tea in China?  Well, this fascination with abstraction, together with its attendant damaging leaks, isn’t just a thing for computer software nerds.  It’s all over the academic world as well.  I keep thinking of these leaky abstractions when I see any academic speaking on any topic. The role of the academic seems, sometimes, to me at any rate, to be to simplify things with abstractions. Sadly, just like in the world of software, those abstractions leak. A whole lot. And as a result they tend to make the world a harder place to navigate.

When you read an academic paper (or even academic brain farts like those appearing in this blog), keep in mind the law of leaky abstractions: All non-trivial abstractions, to some degree, are leaky.  While you’re ooh-ing and ah-ing over the elegant expression of an idea that you’ve stumbled over, keep your mind active.  Look for those inevitably-appearing leaks and be ready to deal with them so you don’t get blinded by beautiful words to your detriment.

—Michael Richter