6 ms·
You are abstracting over a CPU and memory. Your abstraction leaks in that memory layout actually matters for performance, for example. Or if you have a bad RAM
by gnud 6y ago
You are abstracting over a CPU and memory. Your abstraction leaks in that memory layout actually matters for performance, for example. Or if you have a bad RAM chip.
- mbrock 6y agoIndeed proof formalisms are themselves leaky abstractions.
- cannabis_sam 6y agoThe theories, the implementations, or both?
- mbrock 6y agoThe theories as conceived to relate to the actual programming environment. Any proof about a Haskell program’s correctness relies on a leaky abstraction (an axiomatization) of what will actually happen when you run GHC on the source file.
- cannabis_sam 6y agoSo implementation then..
- mbrock 6y agoThe theory is supposed to be an abstraction of the implementation, not the other way around...
- cannabis_sam 6y agoSupposed by whom?
- lmm 6y ago> Your abstraction leaks in that memory layout actually matters for performance, for example. There are cache-aware abstractions if your situation warrants them. Of course if you abstract over a detail then you lose control over that detail. But that's not the same as a leak, and it's the very essence of programming at all; if the program needs to behave differently every time it runs, then creating a useful program is impossible. > Or if you have a bad RAM chip. That's another example of what I said about garbage in, garbage out. The fault isn't in the abstraction, the fault is the bad RAM chip. If you were manually managing all your memory addresses then a bad RAM chip would still present the same problem.
- Koshkin 6y agoRight. As they say, In theory there is no difference between theory and practice; in practice, there is.
- dllthomas 6y agoGet better theory.
- dllthomas 6y agoHuh, I just realized that this was ambiguous, and people might be (validly) interpreting as "Get better theory [and there won't be a difference!]" For the record, I meant "Get better theory, and your theory can also talk about the difference between practice and theory."
- TheCoelacanth 6y agoI would argue that the "correct" behavior of a RAM chip is an abstraction over the actual physical behavior. That abstraction leaks when the actual physical behavior of a RAM chip differs from the abstract specification that it implements.
- lmm 6y agoThat's not exactly false, but at that point you might as well say that anything that breaks is an abstraction leak. If my car won't start in the morning, is that an "abstraction leak"? I don't think it is (or at least I don't think it's a useful perspective to see it as one), because the problem wasn't that I was thinking of the abstract notion of a car rather than the details of a bunch of different components connected together in particular ways; the problem is that one or more of those components is broken (or maybe that some of the components are put together wrong).
- watwut 6y agoYeah, and that is still completely pointless observation, because literally nothing I do will change because of it. Because if abstraction leaks in these edge cases, we are still better off trying to come up with same abstractions then not.
- wtetzner 6y ago> You are abstracting over a CPU and memory. Your abstraction leaks in that memory layout actually matters for performance, for example. I find the idea that an abstraction is leaky if different implementations of it perform differently to be fairly useless. I don't think it's a useful concept unless the abstraction captures the expected performance. If the abstraction doesn't give any performance guarantees, then the caller shouldn't have any performance expectations. Similarly to abstractions around accessing a file on disk that might fail. The abstraction should account for potential failures. If it doesn't account for failures, but the implementation does fail, then it's meaningful to call it leaky.
- AnimalMuppet 6y agoPerformance matters sometimes. If you're in a situation where performance matters, and the abstraction doesn't capture the expected performance, but you're subject to the abstraction's actual performance anyway, then the abstraction leaked in a way that matters to you.
- chowells 6y agoYou've found that the abstraction isn't useful for doing your task. That's not leaking. That's like complaining that your ice cream maker can't cook rice. That's not what it's for. In fact, this is a common manner for abstractions to become leaky. You find you are in need some guarantee not present in the abstraction. You choose to add whether or not that guarantee is satisfied to the shared interface. Congratulations! You've added a leak to the abstraction. But that's not the only option available. If you need a guarantee not provided by an abstraction, you could ignore the abstraction and use something that actually provides the guarantees you need.
- AnimalMuppet 6y agoI have to care about what's inside it (to know whether the performance is up to what I need) rather than just the interface. To me, that's leaking. For example, if I have to care whether the "collection" is implemented as a linked list or as a vector, the the "collection" abstraction has leaked.