4 ms·

By this logic though, aren't all abstractions leaky in the end? edit: not arguing, just curious. I haven't thought much about abstraction but it seems like it

By this logic though, aren't all abstractions leaky in the end? edit: not arguing, just curious. I haven't thought much about abstraction but it seems like it could be a truism that every conceivable abstraction could succumb to this problem in some way.

wsy 8y ago
You can only answer that with respect to a specific usage of the abstraction. An abstraction that should abstract from different implementations A, B, C is leaky with respect to use case X, if the implementation for X still needs to know about differences between A/B/C. A good abstraction is not leaky for most use cases. A bad abstraction is leaky for many use cases. The main issue is that you can't foresee the use cases, so premature abstractions usually turn out to be leaky.
gameswithgo 8y ago
>By this logic though, aren't all abstractions leaky in the end? Almost all. the question is just one of degree. The fact that they are almost all leaky is why you should be hesitant to abstract away in the first place. The effort you think you are saving may be taken up later when the leaky details bite you. "I'll use this game engine instead of raw vulkan" -> "oh no I can't render all my widgets fast enough on mobile" or "I'll use this easy UI library" -> "oh no I can't actually do a list of text boxes that is scrollable with this"
tabtab 8y ago
Whether perfect abstractions "could" be made is mostly moot because in practice they are not. The reasons include but are not limited to: 1) Humans make mistakes and are often ambiguous. 2) Perfection is often not economical. 98% good enough may require 1/10 the code of 99.9% perfect and customers don't want to pay for 10x the coding. See: https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better 3) New standards or technology comes along that challenge the original assumptions made. (I gave an example of OOP GUI libraries versus Web elsewhere.) 4) Performance: heavy-handed abstractions are often too slow because they have more conditionals and converters/fixers to adjust the translations or interfaces.

wsy 8y ago

You can only answer that with respect to a specific usage of the abstraction. An abstraction that should abstract from different implementations A, B, C is leaky with respect to use case X, if the implementation for X still needs to know about differences between A/B/C. A good abstraction is not leaky for most use cases. A bad abstraction is leaky for many use cases. The main issue is that you can't foresee the use cases, so premature abstractions usually turn out to be leaky.

gameswithgo 8y ago

>By this logic though, aren't all abstractions leaky in the end? Almost all. the question is just one of degree. The fact that they are almost all leaky is why you should be hesitant to abstract away in the first place. The effort you think you are saving may be taken up later when the leaky details bite you. "I'll use this game engine instead of raw vulkan" -> "oh no I can't render all my widgets fast enough on mobile" or "I'll use this easy UI library" -> "oh no I can't actually do a list of text boxes that is scrollable with this"

tabtab 8y ago

Whether perfect abstractions "could" be made is mostly moot because in practice they are not. The reasons include but are not limited to: 1) Humans make mistakes and are often ambiguous. 2) Perfection is often not economical. 98% good enough may require 1/10 the code of 99.9% perfect and customers don't want to pay for 10x the coding. See: https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better 3) New standards or technology comes along that challenge the original assumptions made. (I gave an example of OOP GUI libraries versus Web elsewhere.) 4) Performance: heavy-handed abstractions are often too slow because they have more conditionals and converters/fixers to adjust the translations or interfaces.