3 ms·
I disagree. All abstractions are leaky, to a certain extent. The abstractions in FP circles are only not considered leaky because performance concerns are ofte
by cloogshicer 3y ago
I disagree. All abstractions are leaky, to a certain extent.
The abstractions in FP circles are only not considered leaky because performance concerns are often secondary, and only correctness is considered.
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
- lmm 3y agoI'm aware of that post and it's bollocks. None of its examples actually work, and even if they did they wouldn't be enough to prove a general law.
- cloogshicer 3y agoI think they make a lot of sense - genuinely curious what you mean. Could you explain in more detail?
- lmm 3y agoWriting your application using UDP rather than TCP doesn't mean it will continue to work when you unplug the network cable. That's not the abstraction leaking, that's the premises being violated. TCP is actually very specific about what it does and doesn't guarantee. That SQL example may have been a real bug in one database 20 years ago, but it's not something that happens in reality. Query planners work well enough that you can't generally beat the query planner - PostgreSQL won't even let you try, quite deliberately. And if you look at even one of the classic FP examples like monoid, not only do they not leak, but you can literally mathematically prove that they don't. If you have two lists of a monoid, sum(a) + sum(b) will always equal sum(a + b). The whole post is just a failure of imagination; rather than proposing that all abstractions are leaky because you can't think of any good ones, a better post would ask what it would take to constitute a valid abstraction and then try to figure out whether that's possible or not.