5 ms·

Can someone better explain the leaky abstraction concept? I take it to mean an abstraction that really isn’t.

V-2 8y ago
It's basically an abstraction that fails to properly abstract away the (complex) reality behind it, which leads to things being more, instead of less, difficult to grasp. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
salawat 8y ago
A leaky abstraction colors your approach to solving problems in ways above and beyond what is minimally needed to solve the problem at hand. For instance, when the author created an HAL instead of a specific problem specific driver, the HAL meant that he had to solve 2 problems instead of 1 The end product had to work, and had to be compatible with the HAL as implemented. The abstraction leaked. Just making the driver would have yielded a solution to the problem that would"t have required as much refactoring of old code. It's a way of saying he made more work for himself than was necessary. A very YMMV observation.
vvanders 8y ago
All abstractions leak just in different degrees. Perf/memory is the most common but there are others as well. Your ivory tower parser/data format/framework is great until you need to fit it in 1/4 the memory or MIPS. That's when you start pulling out the abstractions to get back to where the product actually needs to be.
- tabtab 8y ago
  One of the biggest industrial-scale examples of abstraction failure is OOP GUI's. They were an abstract interface, meaning in theory they could adapt to ANY future UI interface or standard. But the "the Web" came and took a shot-gun to it by not preserving program state, and by mostly forcing one to let the client determine the final layout (positioning). The existing OOP GUI engines ASSUMED the engine controlled both state and final positioning, because it had usually been that way in the past. But Web-land said, "Sorry, Dave, I cannot do that.", and so the engines were largely abandoned in back dumpsters. (Web UI can turn one prematurely grey, but that's another story.)
ben509 8y ago
A leaky abstraction is one that mostly works, but details and assumptions leak through. For example, many languages attempt to provide a cross-platform API for filesystems; they give you an algebra that lets you construct and manipulate paths. So if you have a Path, the `/` abstract operator might join path parts, and "basename" and "dirname" are functions that extract parts of the pathname. Typically, the API designer makes some intentional (and some unintentional) design decisions to keep the API comprehensible but at the expense of being inconsistent with the underlying reality being abstracted. As an example, some filesystems are case-insensitive, others aren't, so to know if two paths refer to the same file, e.g. if you want to use paths as keys, you need to determine what volume each is on. This gets complicated in Unix due to symlinks (which can be any component of a path) and mounts that can be anywhere in the tree. You could resolve a path to an inode, but then other filesystems might not provide an inode.
- tenaciousDaniel 8y ago
  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"
wsy 8y ago
While I agree with the author with respect to his main point, I think the term leaky abstraction side-tracks the discussion. It is simply about wrong abstractions. See also: https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...
nextos 8y ago
A good example are SQL queries. You can have two semantically equivalent queries i.e, two queries that will always return the same results. However, runtime may be dramatically different. One may take a second, and the other one days. That's because SQL is an imperfect abstraction. It isolates you from the underlying details on how to compute the results of a query, but only to some extent. On many occasions you need to actually understand how the declarative query is translated into an execution plan.
- parsnips 8y ago
  So sorting is a leaky abstraction? Because merge sort and bubble sort can both have the same interface, isolating you from underlying details...
  - elvinyung 8y ago
    Yes, exactly. The slowness of the bubble sort "leaks" the fact that it's a bad/naive implementation of sorting.
    - tabtab 8y ago
      Abstraction is often defined similar to "hiding irrelevant details" so that one can focus on the forest instead of the trees. However, sometimes tree-level issues affect the forest view also. An unexpectedly slow sort operation may be such a case. Normally you cay "ORDER BY x" in SQL and not worry about HOW the RDBMS sorts on "x": "How" is a "grunt-level detail" to you. But if the sort is slow or "wrong" (such as a collating sequence not expected by the customer), THEN you have to dig into the details, stepping out of the abstraction forest to visit and study individual trees.

V-2 8y ago

It's basically an abstraction that fails to properly abstract away the (complex) reality behind it, which leads to things being more, instead of less, difficult to grasp. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

salawat 8y ago

A leaky abstraction colors your approach to solving problems in ways above and beyond what is minimally needed to solve the problem at hand. For instance, when the author created an HAL instead of a specific problem specific driver, the HAL meant that he had to solve 2 problems instead of 1 The end product had to work, and had to be compatible with the HAL as implemented. The abstraction leaked. Just making the driver would have yielded a solution to the problem that would"t have required as much refactoring of old code. It's a way of saying he made more work for himself than was necessary. A very YMMV observation.

vvanders 8y ago

All abstractions leak just in different degrees. Perf/memory is the most common but there are others as well. Your ivory tower parser/data format/framework is great until you need to fit it in 1/4 the memory or MIPS. That's when you start pulling out the abstractions to get back to where the product actually needs to be.

tabtab 8y ago
One of the biggest industrial-scale examples of abstraction failure is OOP GUI's. They were an abstract interface, meaning in theory they could adapt to ANY future UI interface or standard. But the "the Web" came and took a shot-gun to it by not preserving program state, and by mostly forcing one to let the client determine the final layout (positioning). The existing OOP GUI engines ASSUMED the engine controlled both state and final positioning, because it had usually been that way in the past. But Web-land said, "Sorry, Dave, I cannot do that.", and so the engines were largely abandoned in back dumpsters. (Web UI can turn one prematurely grey, but that's another story.)

ben509 8y ago

A leaky abstraction is one that mostly works, but details and assumptions leak through. For example, many languages attempt to provide a cross-platform API for filesystems; they give you an algebra that lets you construct and manipulate paths. So if you have a Path, the `/` abstract operator might join path parts, and "basename" and "dirname" are functions that extract parts of the pathname. Typically, the API designer makes some intentional (and some unintentional) design decisions to keep the API comprehensible but at the expense of being inconsistent with the underlying reality being abstracted. As an example, some filesystems are case-insensitive, others aren't, so to know if two paths refer to the same file, e.g. if you want to use paths as keys, you need to determine what volume each is on. This gets complicated in Unix due to symlinks (which can be any component of a path) and mounts that can be anywhere in the tree. You could resolve a path to an inode, but then other filesystems might not provide an inode.

tenaciousDaniel 8y ago
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"

wsy 8y ago

While I agree with the author with respect to his main point, I think the term leaky abstraction side-tracks the discussion. It is simply about wrong abstractions. See also: https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...

nextos 8y ago

A good example are SQL queries. You can have two semantically equivalent queries i.e, two queries that will always return the same results. However, runtime may be dramatically different. One may take a second, and the other one days. That's because SQL is an imperfect abstraction. It isolates you from the underlying details on how to compute the results of a query, but only to some extent. On many occasions you need to actually understand how the declarative query is translated into an execution plan.

parsnips 8y ago
So sorting is a leaky abstraction? Because merge sort and bubble sort can both have the same interface, isolating you from underlying details...
- elvinyung 8y ago
  Yes, exactly. The slowness of the bubble sort "leaks" the fact that it's a bad/naive implementation of sorting.
  - tabtab 8y ago
    Abstraction is often defined similar to "hiding irrelevant details" so that one can focus on the forest instead of the trees. However, sometimes tree-level issues affect the forest view also. An unexpectedly slow sort operation may be such a case. Normally you cay "ORDER BY x" in SQL and not worry about HOW the RDBMS sorts on "x": "How" is a "grunt-level detail" to you. But if the sort is slow or "wrong" (such as a collating sequence not expected by the customer), THEN you have to dig into the details, stepping out of the abstraction forest to visit and study individual trees.