I've long been having a hunch that we're currently in the "wild west of abstraction".<p>I think we're missing an essential constraint on the way we do abstraction.<p>My hunch is that this constraint should be that abstractions <i>must</i> be reversible.<p>Here's an example: When you use a compiler, you can work at a higher layer of abstraction (the higher-level language). But, this means you're now <i>locked into</i> that layer of abstraction. By that I mean, you can no longer work at the lower layer (assembly), even if you wanted to. You could in theory of course modify the compiler output after it's been generated, but then you'd have to somehow manually keep that work in sync whenever you want to re-generate. Using an abstraction kinda locks you into that layer.<p>I see this problem appearing everywhere:<p>- Use framework <--> Write from scratch<p>- Use an ORM <--> Write raw SQL<p>- Garbage collection <--> Manual memory management<p>- Using a DSL <--> Writing raw language code<p>- Cross platform UI framework <--> Native UI code<p>- ...<p>I think we're missing a fundamental primitive of abstraction that allows us to work on <i>each layer</i> of abstraction without being locked in.<p>If you have any thoughts at all on this, please share them here!
I never liked the way he used TCP as an example here.<p>I don't think it's sensible to think of "make it reliable" as a process of abstraction or simplification (it's obviously not possible to build a reliable connection on top of IP if by "reliable" you mean "will never fail"). "You might have to cope with a TCP connection failing" doesn't seem to be the same sort of thing as his other examples of leaky abstractions.<p>TCP's abstraction is more like "I'll either give you a reliable connection or a clean error". And that one certainly does leak. He could have talked about how the checksum might fail to be sufficient, or how sometimes you have to care about packet boundaries, or how sometimes it might run incredibly slowly without actually failing.
I first learned about "leaky abstractions" from John Cook, who describes* IEEE 754 floats as a leaky abstraction of the reals. I think this is a good way of appreciating floating point for the large group of people who's experience is somewhere between numerical computing experts (who look at every arithmetic operation through the lens of numerical precision) and total beginners (who haven't yet recognized that there can't be a one-to-one correspondence between a point on the real number line and a "float").<p>* <a href="https://www.johndcook.com/blog/2009/04/06/numbers-are-a-leaky-abstraction/" rel="nofollow">https://www.johndcook.com/blog/2009/04/06/numbers-are-a-leak...</a>
I feel like this article should be called "The Law of Bad Abstractions." I often see this cited as a blanket rejection of complexity in software. But complexity is unavoidable and even necessary. A skillful engineer will therefore design their abstractions carefully and correctly, balancing time spent thinking forward against time spent implementing a solution. I think Joel understands this, but it feels weird how he frames it as a "law", as though it's something he's discovered instead of a simple fact that arises from the nature of what abstractions are: things that stand in for (or mediate interaction with) some other thing without actually being that thing. What a surprise that the stand-in ends up not being the actual thing it's standing in for!
A car is an implementation meant to deal with a problem (the weather), but never abstracts away physics or forces full buy-in to some alternate reality. You can’t just go around and say any imperfection in an implementation is a leaky abstraction. That’s not how it works.<p>My shoe is not abstracting away the terrain, nor is it leaky because it doesn’t handle <i>all</i> weather conditions. Well, it is leaky, but not in that sense.
Young people should probably know that (as far as I recall) Joel more or less invented tech blogging as a form of advertising/recruiting for your company.<p>Namely either listing out the process/perks that a good engineering team should have and how conveniently his company has it. Or describing interesting and challenging problems they solved and how you can join them and solve problems like that too.<p>I don't recall anyone popular doing it before him and it's pretty much industry standard now. (Although, feel free to chime in if that's wrong. But popular being a key word here),
I loved this essay when it came out but I've come to dislike how "leaky abstraction" has become a form of low effort criticism that gets applied to almost anything.
I love this essay so much. I read it 22 years ago and it's been stuck in my mind ever since: it taught me that any time you take on a new abstraction that you don't understand, you're effectively taking on mental debt that is likely to come due at some point in the future.<p>This has made me quite a bit more cautious about the abstractions I take on: I don't have to understand them fully when I start using them, but I do need to feel moderately confident that I could understand them in depth if I needed to.<p>And now I'm working with LLMs, the most opaque abstraction of them all!
If you like this, my other favorite essay by Joel is Making Wrong Code Look Wrong:<p><a href="https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/" rel="nofollow">https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...</a>
This is wrong and even just looking at the examples is enough to understand that it's wrong. Writing your program to use UDP instead of TCP won't make it work any better when someone unplugs the network cable. An abstraction performing worse isn't a "leak" - the abstraction is still doing what it said it would (e.g. the SQL query still returns the right results), and in practice very few query planners are worth tuning manually (indeed PostgreSQL doesn't even offer you the ability to do hints etc., and that doesn't seem to hurt its popularity). I've never understood why this post was so popular - it only ever seems to be used as an excuse for those who want to write bad code to do so.
Are "models" and "abstractions" the same thing?<p>A recent post, `Mental Models: 349 Models Explained...` reminded me of the `Debits and Credits Model`, which works because of the Debit and Credits Formula or Accounting Equation (Assets = Equity + Liabilities). Minor leaks happening here and are usually stuffed into an account--so we don't have to eat lunch at our desks.<p>The abstraction examples seem similar, but the discussion around leakage is interestingly different. For example @anonymous-panda suggests you sometimes want your abstraction to be leaky: _ "...leaky abstraction would be when you need to still distinguish the error type and TCP wouldn’t let you..."_
Building White-Box Abstractions by Program Refinement[1]<p>[1]: <a href="https://people.inf.ethz.ch/suz/publications/onward16.pdf" rel="nofollow">https://people.inf.ethz.ch/suz/publications/onward16.pdf</a>
> But sometimes the abstraction leaks and causes horrible performance and you have to break out the query plan analyzer and study what it did wrong, and figure out how to make your query run faster<p>Hah. The more things change, the more they stay the same.
> “All abstractions leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.”<p>Very nicely worded. But I would also add that:<p>1. An abstraction can often be manned by one person, so when it leaks only one person needs to understand it deeply enough to fix it.<p>2. The article seems to miss the <i>iterative</i> nature of abstractions. Over time, the goal is to iterate on the abstraction so that it exposes more of the stuff that matters, and less of the stuff that doesn’t matter. Perhaps all abstractions leak, but some leak way less often and save much more thinking in the meantime than others. Rather than lamenting the nature of abstractions we should focus effort on making them as practically useful as possible.
This is well-written. I might suggest that what makes pure mathematics special is that abstractions in pure math are not leaky, unlike in (nearly?) every other domain.
Joel of course hits the nail on the head about the two major things that cause abstractions to fall apart: performance and bugs (or debugging). In programming languages we talk about abstractions all the time--PL of course is all about abstractions. A computational abstraction like a bytecode, source language, or even machine code, can be proven be a proper (or full) abstraction, meaning there is no way for implementation details to leak in--you cannot observe the electrons flowing by executing A+B, after all.<p>...until you start measuring sidechannels, or the CPU or compiler has a bug.<p>I think about this a lot when dealing with VMs; a complex VM cannot hide its complexity when programs care about execution time, or when the VM actually has a bug.
> Back to TCP. Earlier for the sake of simplicity I told a little fib, and some of you have steam coming out of your ears by now because this fib is driving you crazy. I said that TCP guarantees that your message will arrive. It doesn’t, actually. If your pet snake has chewed through the network cable leading to your computer, and no IP packets can get through, then TCP can’t do anything about it and your message doesn’t arrive.<p>The argument is disqualified at this point. The whole world is a leaky abstraction because <freak meteor hit could happen>. At this point your concept is all-encompassing and in turn useless.<p>There are assumptions: this computation will finish eventually [assuming that no one unplugs the computer itself]. This does not make things leaky.<p>There are leaky abstractions I guess but not all are. A garbage collector that can cause memory errors would be leaky. I don’t know anything about garbage colletors but in my experience they don’t.<p>Then someone says that a garbage collector is leaky because of performance concerns (throughput or latency). That’s not a leak: that’s part of the <i>abstracting away</i> part—some concerns are <i>abstracted away</i>. To abstract away means to make it something that you can’t fudge or change. To say that “this is implementation-defined”. An abstract <i>list</i> is an abstraction in the sense that it has some behavior. And also in the sense that it doesn’t say <i>how</i> those behaviors are implemented. That’s both a freedom and a lurking problem (sometimes). Big reallocation because of amortized <i>push</i>? Well you abstracted that away so can you complain about it? Maybe your next step is to move beyond the abstraction and into the more concrete.<p>What are abstractions without something to abstract away? They are impossible. You have to have the freedom to leave some things blank.<p>So what Spolsky is effectively saying is that abstractions are abstractions. That looks more like a rhetorical device than a new argument. (Taxes are theft?)<p>EDIT: Flagged for an opinion? Very well.