Re:Leaky Abstractions
by lmm on Wednesday June 02, 2021 @10:27PM
(#27376577)
IMO that article is the most damaging thing to happen to programming culture in 20 years. It's not hard to write a valid abstraction, and none of Joel's examples actually hold up (yet he generalises it to a supposedly universal law). Of course abstractions are garbage-in, garbage-out - yes, TCP won't give you a reliable connection if you unplug the network cable, but an application written to use UDP won't fare any better in that case.
[ Parent
| on HN ]
TCP won’t give you a reliable connection if you tunnel TCP over TCP, paradoxically, but you can tunnel TCP over UDP, UDP over TCP, or UDP over UDP. Leaky!
Not "leaky", the conditions that a TCP connection needs its underlying transport to satisfy are explicitly documented, and TCP doesn't conform to them.
If you're going into the details of what conditions a TCP connection needs, you're no longer talking about an abstraction.
An abstraction doesn't mean you can close your eyes and everything will work by magic. They're extremely useful tools, but like I said: garbage in, garbage out.
> An abstraction doesn't mean you can close your eyes and everything will work by magic.
Right... that's why they're called "leaky abstractions". Because when you don't pay attention to the implementation details and their constraints, things break.
If it weren't leaky, you'd call it a "specification" instead of an "abstraction".
Requirements are not the same thing as implementation details. 2 + 2 = 4 is a sound abstraction, the fact that 1 + 2 doesn't = 4 doesn't make it "leaky".
2 + 2 = 4 isn't an abstraction. I think we just have a different idea of what an "abstraction" is, which is fine.
Re:Leaky Abstractions
by tacitusarc on Thursday June 03, 2021 @12:56AM
(#27377376)
It sounds like you completely missed the point he’s trying to make...