Live data from Hacker News

The Law of Leaky Abstractions (2002)

joelonsoftware.com

11–20 of 93 posts

Re: The Law of Leaky Abstractions (2002)

#11

If 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-...

The problem is that it completely ignores the correct solution, which is "use types; we invented them for a reason".

HTML fragments should never be stored in strings.

Re: The Law of Leaky Abstractions (2002)

#12

> 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…

I tend to agree. "All nontrivial abstractions are leaky" reminds me of other slightly-too-cute rules, such as "full rewrites are a mistake" and "never parse JSON manually".

I wouldn't call TCP leaky because it can't deliver data across a broken network cable, for example. It's abstracting away certain unreliable features of the network, like out of order delivery of packets. It's not abstracting away the fact that networking requires a network.

Re: The Law of Leaky Abstractions (2002)

#14
post #8

I 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.…

Indeed, his discussion seems to involve a confusing of a leaky network protocol and a leaky abstraction. Perhaps he wanted to meta-illustrate his concept by having his discussion itself be leaky.

Re: The Law of Leaky Abstractions (2002)

#15
> “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.”

Very nicely worded. But I would also add that:

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.

2. The article seems to miss the iterative 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.

Re: The Law of Leaky Abstractions (2002)

#16

> 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…

I unflagged you by vouching for you. I found your post difficult to understand and couldn't figure out what you are trying to say, but I agree it was not deserving of a flag.

Re: The Law of Leaky Abstractions (2002)

#17

Cannot everyone get the sense that how we currently build software is one gigantic leaky abstraction?

Worse; it's a stack of abstractions on top of abstractions on top of abstractions. You're at least 10 layers away from the hardware, possibly more.

Re: The Law of Leaky Abstractions (2002)

#18
post #16

> 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…

I unflagged you by vouching for you. I found your post difficult to understand and couldn't figure out what you are trying to say, but I agree it was not deserving of a flag.

What was difficult about what I wrote?

Re: The Law of Leaky Abstractions (2002)

#20

> 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…

I don't agree with your opinion, but I see how it can be seen as being perfectly reasonable and there really is no need to flag you (unflagged).
Post reply on HN