The Law of Leaky Abstractions (2002)
joelonsoftware.com
The Law of Leaky Abstractions (2002)
1–10 of 93 posts
Re: The Law of Leaky Abstractions (2002)
#2Should have (2002) in title.
Re: The Law of Leaky Abstractions (2002)
#3[deleted]
Re: The Law of Leaky Abstractions (2002)
#4I 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.
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.
And now I'm working with LLMs, the most opaque abstraction of them all!
Re: The Law of Leaky Abstractions (2002)
#5> 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.
The argument is disqualified at this point. The whole world is a leaky abstraction because . At this point your concept is all-encompassing and in turn useless.
There are assumptions: this computation will finish eventually [assuming that no one unplugs the computer itself]. This does not make things leaky.
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.
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 abstracting away part—some concerns are abstracted away. To abstract away means to make it something that you can’t fudge or change. To say that “this is implementation-defined”. An abstract list is an abstraction in the sense that it has some behavior. And also in the sense that it doesn’t say how those behaviors are implemented. That’s both a freedom and a lurking problem (sometimes). Big reallocation because of amortized push? 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.
What are abstractions without something to abstract away? They are impossible. You have to have the freedom to leave some things blank.
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?)
EDIT: Flagged for an opinion? Very well.
Re: The Law of Leaky Abstractions (2002)
#6If you like this, my other favorite essay by Joel is Making Wrong Code Look Wrong:
https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...
Re: The Law of Leaky Abstractions (2002)
#7> 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 doe…
[deleted]
Re: The Law of Leaky Abstractions (2002)
#8I never liked the way he used TCP as an example here.
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.
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.
Re: The Law of Leaky Abstractions (2002)
#9I 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. 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…
>And now I'm working with LLMs, the most opaque abstraction of them all!
You put a black box around it to fit it into the world of abstractions that traditional programs live in.
But I'd say the most interesting thing about neural networks is that they do not have any abstractions within them. They're programs, but programs created by an optimization algorithm just turning knobs to minimize the loss.
This creates very different kinds of programs - large, data-driven programs that can integrate huge amounts of information into their construction. It's a whole new domain with very different properties than traditional software built out of stacked abstractions.
Re: The Law of Leaky Abstractions (2002)
#10Young 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.
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.
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),