Leaky Abstractions Are Not


In 2002 Joel Spolsky argued that “All non-trivial abstractions, to some degree, are leaky”.  As a result, there have been numerous programmers who have used this as an excuse to throw away numerous abstractions in favor of lower-level alternatives. The original argument though is a straw man and the perpetuation of it is actively harmful to the industry.

The Straw Men Cometh

Joel’s examples and the numerous other examples I’ve seen subsequently by proponents all fall into the same categorical error, namely: ascribing an expectation or requirement on an abstraction or model that was never there to begin with. To counter some of the specific claims:

  1. TCP never specified that it would guarantee successful delivery of all data in all situations, nor did it guarantee a speed for delivery. It is very clear in what it means with the terms “reliable” as well as the rules about when and how a connection will timeout and be closed: https://tools.ietf.org/html/std7#section-2.6 . Oversimplifying this by assuming guaranteed transmission and speed is simply incorrect.
  2. Iteration strategy over a two-dimensional array + Page Faults: There is no programming language in common use today that makes a guarantee about such iteration performance. Assuming one is not the fault of the language that didn’t specify one. The abstractions did not fail nor leak in these cases either.
  3. Complaints about SQL performance: Again, the same problem as #2. Running two semantically equivalent queries will give you the same result, but there was no performance guarantee. Assuming one is again not the fault of the abstraction but with the expectation
  4. And so on and so on…

Expectations Meet Reality

Expectations of reality and reality itself are two different things. If an abstraction/model does not explicitly make claims about some aspect of interest it does not mean that it has leaked or failed, it’s simply the wrong one for what you’re concerned with.  Build a better model or use one which claims to fulfill your requirements (and can demonstrate it).

Dreaming an Ocean of Code

Once as I laid in bed a twilight dream came to me. This dream was a vision of code. All scopes were colored purple and blue and were in conflict with one another. These colors were not static but fluid and flowed through the contours of function calls and methods.  The colors burned each other where they met and a smoke rose from the boundaries. Across this landscape of contoured antipodes I could also see pits and pillars. Every contradiction in logic was a singularity eating the area around it. The pillars were in fact swells where some Leviathan of code laid beneath and pulled the surrounding fluid above it like a tide. I could not perceive what this code was for as I was too close to it as it swept me along. Soon I awoke, wondering what it was that I discovered.