3 ms·

>The Law of Leaky Abstractions is a lie; abstract airtightly. Man, when I read things like this about "design principles" I know I'm getting into a bag of hand

>The Law of Leaky Abstractions is a lie; abstract airtightly. Man, when I read things like this about "design principles" I know I'm getting into a bag of hand wavy opinions with no rigid theoretical proofs. That's fine because not everything is covered. But the minute you say something that is outright false I know you're worthless. All abstractions leak. I cannot make an abstraction perform better than what's underneath. The performance leaks through every single time. An abstraction will always only be worse performing then what's underneath simply due to the cost overhead of the abstraction itself. Rust is a great example. It has something called zero cost abstractions, meaning that the abstractions that Rust uses are more complicated than normal in order to maintain the zero performance cost. That is leakage. There is always a cost.

xiphias2 7y ago
When GMail was launched, everybody was amazed of how fast it ran. The way it was optimized for IE6 was that the team decompiled it and understood how the JavaScript engine and the garbage collector were working underneath and got around them. The team went out their way to optimize for the large number of emails that are used insided Google. The project of course was a huge success.
- crimsonalucard 7y ago
  When DOOM game came out everybody was amazed as well. Same with windows and osx. Many things about computers were understood during this time and were huge successes. But did you know that the fourier wave hit quantum apex and therefore logic was inescapable. But what's most amazing is how irrelevant your post is to what I'm talking about.
  - AnimalMuppet 7y ago
    If I understand, xiphias2 is agreeing with you - that Gmail went "behind" the abstractions, and was the better for it. That is, when you pushed the abstractions as far as GMail needed to, the abstractions leaked.
naasking 7y ago
> All abstractions leak. I cannot make an abstraction perform better than what's underneath Performance is not within the scope of abstraction. This is a category error. Also, your claim is incorrect as a general statement. The type structure of a given program is an abstraction of its value flow, but without that abstraction a compiler would not be able to optimize it nearly as well. A typed program will always be faster than an equivalent untyped program. Creating an abstraction may also allow you to add a transparent memoization layer, which not only can make your program orders of magnitude faster, it can make previously unsolvable problems solvable (see how PEGs handle left recursion).
- AnimalMuppet 7y ago
  > > All abstractions leak. I cannot make an abstraction perform better than what's underneath > Performance is not within the scope of abstraction. This is a category error. It's not within the scope of abstraction... until it is. When that beautiful abstraction does exactly what you need, but does it too slowly to be usable in your circumstances, performance is not separable from the abstraction. (I mean, yes, performance is part of the implementation of the abstraction, not the abstraction itself. But the moment I have to care about the implementation of an abstraction rather than the abstraction itself, the abstraction has leaked. Performance is absolutely one of the ways that this can happen.) And, as a concrete example, the STL went to great lengths to specify the performance of their abstractions.
  - naasking 7y ago
    > But the moment I have to care about the implementation of an abstraction rather than the abstraction itself, the abstraction has leaked. No, that's not what leaky abstraction means. If an abstraction specifies its performance properties, but those properties depend on context that isn't captured by or enforced by the abstraction, that's a leak. To use your example of the STL, if you can allocate a fast constant-time abstraction at a misaligned address, thus causing it to violate its own performance specification, that's a leaky abstraction. Having the wrong performance characteristics simply means it's the wrong abstraction, not that the abstraction is leaky.

xiphias2 7y ago

When GMail was launched, everybody was amazed of how fast it ran. The way it was optimized for IE6 was that the team decompiled it and understood how the JavaScript engine and the garbage collector were working underneath and got around them. The team went out their way to optimize for the large number of emails that are used insided Google. The project of course was a huge success.

crimsonalucard 7y ago
When DOOM game came out everybody was amazed as well. Same with windows and osx. Many things about computers were understood during this time and were huge successes. But did you know that the fourier wave hit quantum apex and therefore logic was inescapable. But what's most amazing is how irrelevant your post is to what I'm talking about.
- AnimalMuppet 7y ago
  If I understand, xiphias2 is agreeing with you - that Gmail went "behind" the abstractions, and was the better for it. That is, when you pushed the abstractions as far as GMail needed to, the abstractions leaked.

naasking 7y ago

> All abstractions leak. I cannot make an abstraction perform better than what's underneath Performance is not within the scope of abstraction. This is a category error. Also, your claim is incorrect as a general statement. The type structure of a given program is an abstraction of its value flow, but without that abstraction a compiler would not be able to optimize it nearly as well. A typed program will always be faster than an equivalent untyped program. Creating an abstraction may also allow you to add a transparent memoization layer, which not only can make your program orders of magnitude faster, it can make previously unsolvable problems solvable (see how PEGs handle left recursion).

AnimalMuppet 7y ago
> > All abstractions leak. I cannot make an abstraction perform better than what's underneath > Performance is not within the scope of abstraction. This is a category error. It's not within the scope of abstraction... until it is. When that beautiful abstraction does exactly what you need, but does it too slowly to be usable in your circumstances, performance is not separable from the abstraction. (I mean, yes, performance is part of the implementation of the abstraction, not the abstraction itself. But the moment I have to care about the implementation of an abstraction rather than the abstraction itself, the abstraction has leaked. Performance is absolutely one of the ways that this can happen.) And, as a concrete example, the STL went to great lengths to specify the performance of their abstractions.
- naasking 7y ago
  > But the moment I have to care about the implementation of an abstraction rather than the abstraction itself, the abstraction has leaked. No, that's not what leaky abstraction means. If an abstraction specifies its performance properties, but those properties depend on context that isn't captured by or enforced by the abstraction, that's a leak. To use your example of the STL, if you can allocate a fast constant-time abstraction at a misaligned address, thus causing it to violate its own performance specification, that's a leaky abstraction. Having the wrong performance characteristics simply means it's the wrong abstraction, not that the abstraction is leaky.