Talk:Leaky abstraction

salutations for the article enhancement

Many thanks to the person who made the excellent enhancement to the article, including improvements in clarity and structure. Especially appreciated is the rework done on the "philosophical" section, which I had not managed to bring to a level suitable for inclusion. If you are still around, I would like to modify the following:

The conjecture that all sufficiently interesting abstractions are leaky thus has profound philosophical ramifications.

with a reference to Incompleteness_theorem, also change "conjecture" to "theorem" ... any feedback on whether that is appropriate? Thanks! dr.ef.tymac 15:58, 14 December 2006 (UTC)

Thanks -

I changed "conjecture" to "idea" - it's not a scientific or mathematical statement, so neither "conjecture" nor "theorem" is totally appropriate. "Law" would work too since it's informal and is used elsewhere.

I'm not sure where you're going with the incompleteness theorem connection...?

206.124.141.188 06:40, 7 January 2007 (UTC)

Controversial philosophical claims

This article makes a radical philosophical claim:

In an epistemological sense, the human concept of any abstraction is always an implementation of deeper abstractions, represented in mental concepts and verbal statements used to convey them

This is just wrong. There are, on the contrary, a multitude of abstractions which are not implementations of deeper abstractions. To take a big example, the Real Numbers had no "implementation" before the 19th century , but this did not impede the development of calculus. On the other hand, the real numbers are an abstraction - the real numbers can be considered as an abstraction of equivalence classes of Cauchy sequences of rational numbers. Mistercupcake 02:49, 12 February 2007 (UTC)

I removed your counter-example based on real numbers pending some form of citation or backup. The contribution you forwarded is interesting, and the example based on real numbers has some merit (although it is still debateable, considering that the human concept of "Number" itself could be claimed as an abstraction and not a 'fundamental truth' [please let's not get into that debate here] ). Nevertheless, the premise forwarded by Spolsky's article (and its corollaries and consequences) form the foundation for this article.

Of course, reasonable people can disagree with Spolsky, but let's try to keep the article from degenerating into a debate based on that disagreement. Counter-examples are of course relevant, but should be at least accompanied with a cite so readers and editors can independently review the credibility and verify the commentator(s) and articles that take issue with Spolsky's premise. dr.ef.tymac 04:42, 15 February 2007 (UTC)

OK, I'm adding a different example. Mistercupcake 03:18, 17 February 2007 (UTC)

That different example didn't even seem to touch on the subject matter of the article, was something missing or left out? The philosophical point on real numbers at least had some relation to this article's subject matter. If you could come up with a cite for that, it'd be much better than just adding a cited reference for something loosely related that people have to strain just to find a connection to this article. Just a thought. dr.ef.tymac 03:30, 17 February 2007 (UTC)

Look, I'm trying to improve this article. I've tried to assume good faith but you've summarily deleted my input on TWO occasions now before asking me to improve the sections. You can't just go around deleting people's input because you don't think it is relevant. Wikipedia is not a space to advance a particular point of view (for instance the point of view of Spolsky's Leaky Abstraction article). It is an encyclopedia and must represent a neutral point of view. See NPOV.

In this particular case, floating point numbers are a data abstraction. The abstraction lays down what you should get when you add, subtract, multiply, and divide two floating point numbers.Mistercupcake 03:04, 18 February 2007 (UTC)

I have to agree with Dreftymac: I don't see where you're going with IEEE. In fact I think it belies a fundamental misunderstanding of the concept being described by the article. Not all bugs are because of leaky abstractions; the bug you described in the Intel processor was simply a bug - the chip didn't do what it was supposed to do. That bug had nothing to do with leaky abstractions. Just because that bug got fixed doesn't mean that floating-point numbers aren't leaky.

On the contrary, floating-point numbers are an excellent example of a leaky abstraction. They attempt to abstract the real numbers, but it's an extremely leaky abstraction because it has limited expressive power both in terms of precision and range. If you program with floating-point numbers, it is very easy to introduce bugs due to the leakyness of the abstraction: if you don't account for the lack of precision you can get rounding errors, and if you don't account for the limited range you can get overflow errors. The nature of the implemetation (using a relatively small, fixed number of bits) bleeds through and corrupts the abstraction (real numbers).

You could say that IEEE isn't really abstracting the real numbers, that floating-point numbers are what they are and the spec is well-defined and self-contained, and any programmer who attempted to use them as though they actually were real numbers is living in a fantasy. And that's exactly Spolsky's point! All abstractions are leaky, so you have to recognize that fact of life and not think that floating-point numbers are actually real numbers, or that paper money is actually money, etc.

Saying that your floating-point example isn't a good example has nothing to do with neutral points of view. It just isn't a good example. Or rather, it isn't a good counter-example (it's a great example).

Going back to your original point, I agree that my statement on epistemology has to be read carefully. It's a claim that all sufficiently interesting concepts are thought of in terms of other concepts. There's a circularity there which is relevant to the article.

206.124.141.188 10:51, 27 February 2007 (UTC)

Pentium bug example

To Mistercupcake: Another contributor already summarized some of the substantive considerations quite well (see above), the only thing I would care to add are some procedural considerations.

First, so far, it seems fair to conclude that none of the recent major contributions to this article represent "bad faith," and that the goal to improve the article is mutual. Secondly, if we could take a moment to "step back" from the subject matter of the article (and the abstruse philosophical implications) I think it would help obviate any unfavorable misunderstandings.

The first time you forwarded material, it was definitely direct, unambiguous and on-topic relative to this article. In fact, it seemed *so* direct and unambiguous as to justify a direct citation, so readers (and indeed other editors) could make a good-faith and independent assessment of its credibility, context and rationale:

... There are, on the contrary, a multitude of abstractions which are not implementations of deeper abstractions.

Taking this on its face (and not its underlying validity or point of view) suggesting "improvement before removal" seemed (procedurally) counterproductive. The statement itself is actually pretty clear. The change to the pentium bug example (and the following modifications) seemed to stray off-topic. Sure there was a cite, but could a reader guess it had anything to do with Spolsky just by reading the cite itself?

I try to express this in purely procedural terms: 1) to avoid letting this talk page, (and the article itself) diverge too far into stylized debates on the subject matter; and 2) to show agreement with you on striving toward neutrality. I respectfully suggest the critical improvement for this instance would be to avoid conclusions that could not be reasonably inferred from the cited references themselves. dr.ef.tymac 16:23, 27 February 2007 (UTC) Update: Sorry, sloppy misstatement, "pentium bug" -> "floating-point counter-example". dr.ef.tymac 16:57, 27 February 2007 (UTC)

It seems to me that Spolsky's law of leaky abstractions is talking about the leakiness of abstractions, and not of their implementation. This seems obviously defensible if someone considers what an abstraction is. X is an abstraction of Y for a goal G, when you consider only the important things of Y in relation to G. Obviously the "important things" is a subset of all properties of Y. The leakiness is caused from the fact that those things that are deemed unimportant and thus not taken in consideration, are sometimes important. That is the leak. So I think that the article is wrong asserting that: "A leaky abstraction is an unsatisfactory implementation of an abstraction." and "The implementation is leaky, not the abstraction.Abstractions are conceptual and are not susceptible to leaks.". Waterpie (talk) 17:03, 18 November 2007 (UTC)

The issue you raise reinforces why this article has multiple subsections: "technical sense"; "generalized sense"; and "philosophical sense".

From one perspective you are correct, and the article is mistaken, from a different perspective you are mistaken, and the article is correct. It all depends on how one chooses to define "abstraction" (an instance based on an abstraction can itself be another abstraction). Perhaps re-read the "philosophical sense" section of the article -- that seems to sum up the apparently "wrong" statement, which under a certain reading of Spolsky, is actually quite correct. It wouldn't be good to remove the "wrong" statement from the article because it is not (entirely) incorrect. dr.ef.tymac (talk) 04:31, 19 November 2007 (UTC)

Without a doubt, this article misunderstands the whole thrust of Spolsky's argument. It is precisely *not* that the implementation of an abstraction may be "unsatisfactory" (let alone that bad implementations cause software bugs, sheesh), but that abstractions *themselves* necessarily involve hiding reality, and as such break down once reality starts to intrude. Thus, you can pretend that CD-ROMs, networks and local hard disks are just "data storage locations", but when you try to use them indistinctly, you find that networks and CD-ROMs are orders of magnitude slower than local hard drives. The abstraction breaks down if you push it too far, but that doesn't mean it's a bad or useless abstraction, or that it could be improved. Spolsky is trying to explain the limits of abstractions, not teaching people to make better ones. Abstraction is, essentially, pretending that related but different things are the same, by hiding the details that make them different. Spolsky is pointing out the error of people who get carried away and imagine that the hidden details don't matter any more.

It's actually hard to believe that this could have been written by someone who read the original article. The whole thing needs rewriting by someone who genuinely understands Spolsky's idea, which, in my view, is an indepensible piece of philosophy for anyone working in software development (and much else besides). LordLiverpool (talk) 14:42, 29 November 2007 (UTC)

This article is plainly wrong

This article is based on a pervasive misunderstanding of Spolsky's concept: his law is talking about abstractions, not their implementations. TCP is a leaky abstraction -- it doesn't matter which implementation you might examine. Similarly, virtual memory is a leaky abstraction, regardless of the particular hardware platform you're looking at (although the properties of different hardware platforms might cause more or less leaks through the VM abstraction -- NUMA, for example). The article then takes this misunderstanding, and piles on a bunch of uninformed original research -- the end result is almost worse than useless. Deserves to be rewritten from scratch. Neilc (talk) 03:49, 16 January 2009 (UTC)

This article is plainly fine

I've read Spolsky's paper. Each of his examples is about an implementation of an abstraction. Words like "abstraction" have specific meanings in fields other than Computer Science. It's appropriate to point that out, and how the concept has been extended to those other fields. This article is not about Spolsky and need not adopt his definitions.

For example, a commenter above who feels that "Spolsky's idea, which, in my view, is an indepensible piece of philosophy for anyone working in software development" notes with disdain that "that abstractions *themselves* necessarily involve hiding reality, and as such break down once reality starts to intrude" - which of course is what this article, as written, reveals. In more rigorous fields, the term "implementation" is used in place of the phrase "once reality starts to intrude". 206.124.141.189 (talk) 09:41, 21 April 2009 (UTC)

This article is wrongly fine

On Wikipedia, this page should only be a summary of a notable concept as described by a notable individual. It should give the gist of the original essay which it relates to, and that's all. The philosophical business to do with quarks, and the attempt to link this to the whole history of Western philosphy, is ridiculously inappropriate. Yes, the originator of that analogy may be out of their depth, but there's no need to even have that debate on Wikipedia. That stuff just shouldn't be on Wikipedia, because it's not part of a NPOV description of this notable topic.

Suggested revised page: Brief summary of the point made in the essay. Link to essay (the purpose of which is to go into depth on the subject). End of topic.

Suggested summary:

Law of Leaky Abstractions comes from Spolsky essay, in which he suggests that abstracts have a cost as well as a benefit; with each new layer of abstractions introduced into software, we still have to understand all the layers beneath it.

NB. the second clause of that single sentence is the key point of the essay, currently not clearly stated on this page!

(And some links demonstrating that the essay is widely cited wouldn't go amiss). earwicker (talk) 13:40, 25 June 2009 (UTC)

I suggest swapping the Talk page and Article.

That would make slightly more sense.

Seconded! This is one of those cases where the Talk Page is way more interesting than the Article! And funnier. 190.194.206.43 (talk) 00:27, 20 December 2016 (UTC)

NPOV Addition

Ive added the NPOV tag. Reasons:

1. There is evidently an edit war here
2. Right upfront it says this whole idea is a misnomer!

Rpm13 (talk) 14:37, 28 August 2009 (UTC)

Dealing with folklore-related Computer Science topics

I'm not sure the issue is edit warring so much as the subject matter itself is capable of many interpretations. That fact reflects in the contributions.

The "misnomer" issue may warrant editing for clarification, but that is more of an editorial and style issue rather than a matter of partiality.

The basic issue here is that there is a certain "folklore" element to the subject matter. This affects other computer science topics within WP as well; such as human readable, loose coupling, duck typing, and Anti-pattern, for just an infinitesimal example. The concepts are familiar to people, but very rarely do any two people give the same definition when asked to explain.

References and citations can help improve this content, but the "folklore" aspect will always be a challenge to anyone who wishes to improve the article. dr.ef.tymac (talk) 17:12, 28 August 2009 (UTC)

Leaving aside the misnomer issue -- which is not quite at the head of the article -- let me just take the very first sentence: A leaky abstraction is a notion applied to implementations of an abstraction.

Now go to Joel's article and do a search for 'implementation' -- what do you find? The word is not used even once in the whole article!

Now if wikipedia does not consider it notable enough to have a leaky-abstraction article -- thats ok -- google takes me to the original well enough. But here its putting the subject and putting content thats original research by an editor who evidently disapproves of the whole idea of the article. Surely this is NPOV?

Since I dont wish to pretend not to have a POV, heres mine (which is 'original research' <wink>)

'Abstraction' and 'Implementation' are themselves abstractions. Reality is not so smooth. And like all abstractions they leak. Rpm13 (talk) 14:03, 29 August 2009 (UTC)

Your strongest point is probably "Original Research" ... since there are indeed no citations to scholarly analysis of the structural, textual, ethical, philosophical, doctrinal or historical attributes of this concept: "leaky abstraction". Nevertheless, as stated previously, WP is full of "folkloric" articles that will *never* be the subject of someone's PhD thesis, but nonetheless (apparently by consensus) seem to warrant inclusion. Indeed, a truly rigorous application of NOR would eviscerate entire subsections of WP Computer Science.

True, but then all those articles should be fixed or deleted. It's just a matter of time. The fact that a bunch of other crazy rule-breaking articles exist on Wikipedia is not a good reason to stop fixing one crazy rule-breaking article. earwicker (talk) 07:50, 26 September 2009 (UTC)

If you really wanted to apply proper NOR scholarly treatment of this subject, you would have to frame it in the context of Objectivist philosophy or philosophy of language or Information Theory or Semiotics or (take your pick). Who wants to get started on that? dr.ef.tymac (talk) 17:46, 5 September 2009 (UTC)

But isn't this article mostly about the term coined by Spolsky? I thought everything else was garbage added by Wikipedians. In which case, shouldn't we summarize Spolsky's article, note its relevance, and forget everything about Information Theory or Objectivism? 201.216.245.25 (talk) 21:16, 28 October 2009 (UTC)

Hear! Hear!! But why not sign your comment? Rpm13 (talk) 14:21, 8 November 2009 (UTC)

This article does not have "Spolsky" in the title

From reading the above, there are two controversies: one about how faithfully this article mimes Spolsky's paper, and one about whether the article is making original claims.

To the Spolsky issue, someone ought to create some new pages like "Spolsky's Paper Entitled 'The Law of Leaky Abstractions'" and "Whether Spolsky Uses Mathematical and Philosophical Terminology In His Papers" and "The Amount of Love Some People Have for Spolsky".

This article is not about Spolsky's paper. The term "Leaky Abstraction" has entered into general use, and it now has a meaning independent of Spolsky. Of course, an article about the term must mention its origin. But the primary purpose of this article must be to provide context about the ways in which the concept is relevant today.

How many significant "general uses" of Leaky abstraction can you find that do not refer back to Spolsky? Rpm13 (talk) 14:02, 16 September 2009 (UTC)

This is the problem - I first heard the idea of "abstractions that leak" from my father in 1992 or thereabouts, in a conversation about Visual Basic (his point being that VB was a huge step forward in abstraction of GUI programming, the C++ approach being comparatively leaky). Could be that the "leaking" metaphor has been in widespread use for decades before Spolsky's article, but without published material to cite, we are stuck with Spolsky's article as the most widely-cited origination of it. earwicker (talk) 07:47, 26 September 2009 (UTC)

I agree with the concern about original research within the article. The problem, in my view, is not the text itself, which consists almost entirely of examples, the truth-value of which is irrelevant. The problem is that the examples are framed such that they are read as statements of fact by many people (such as whoever marked the money example up with "Citation Needed"). I'm not sure how to fix that. Are there precedents from other philosophy articles? 206.124.141.189 (talk) 06:31, 14 September 2009 (UTC)

Other than providing cites to all material facts, there does not seem to be an easy solution. In this context, the examples obviously do not constitute material facts, but rather the assertions: 1) that this concept is indeed in general use; 2) that this concept is relevant today (or historically relevant); and 3) that this concept (regardless of its origins) can be defined according to one or more reliable sources, independent of the opinions and examples given by article contributors. dr.ef.tymac (talk) 06:42, 14 September 2009 (UTC)

Not having read Spolsky's books, I cannot cite them in the article; however, the article is in the uncomfortable position of depending on a blog entry rather than a print entry. --Ancheta Wis (talk) 10:53, 3 February 2010 (UTC)

Gregor Kiczales

The notion of abstraction involves keeping things separate, and inherent in this is the concern that the things may mix themselves up again, and so it is hardly surprising that the word "leak" would arise in this context.

This article, per its title, is about the phrase "leaky abstraction", and was almost certainly originally created due to an article by Joel Spolsky. So if this article is about anything, it's about the popularisation of that specific phrase by Spolsky. I'm sure Spolsky was *not* the first to use it, but I have no references to prove it.

An overview section appeared at the top of the article, crediting Gregor Kiczales as the source of the term "leaky abstraction". A link to a PDF of a paper by him was added to the top of the external links list.

But the term "leaky abstraction" does not appear anywhere in the paper. He uses the work "leak" in the context of abstractions. This might have meant that he could be credited with originating a vague metaphor about abstractions, but he only uses the word "leak" when describing the point of another paper about software abstractions, so apparently this is evidence that he did not originate the idea.

So I've deleted the overview section entirely, but left the link to the external article with a more accurate explanation of what it contains. This only improves the article very slightly, but it's a start. earwicker (talk) 08:18, 26 September 2009 (UTC)

I have added references for the concept, which do not use the term "leaky abstraction" either. Rather, the references are polemics designed to pierce the barrier of self-satisfaction of practitioners who hide behind the the shields of their profession because they are not understood by laymen. When the purported abstractions fail, then the shields of protection fail; the details are then exposed. For Taleb, the practitioners he is unmasking live in the financial industry. For Lakatos, the practitioners he is unmasking are mathematicians. For Feyerabend (who is not currently cited) the practitioners he is unmasking are scientists. And of course, scientists are well known for having unmasked religions. One of the goals of good art is to unmask the hidden assumptions of society. As you can see, the article is actually applied many places, but not necessarily under its present name (which is as good as any other, so why not use it). --Ancheta Wis (talk) 10:58, 3 February 2010 (UTC)

This article is primarily about a TERM, not the abstract concept, which is poorly undocumented.

Getting back to the basic quality of this article, I feel it is unsuitable as an introduction to the Computer Science (CS) jargon "Law of Leaky Abstractions." For example: I can't really email a link to this article to reinforce my own use of this term in a specific context (discussing a computer systems problem). I think that's the (very encyclopedic) primary use case for this page. The abstract concept of "leaky abstractions" is actually secondary to the actual facts of the term's connotative usage.

To document one person's expectations:

• Etymology. This is Wikipedia, even a bad one or incomplete one will do for now. There's too much quibbling that crosses the line between an etymology and epistemology.
• Epistemology. The concept is about the limits of knowledge. Though this particular expression is CS jargon, it is appropriate to refer to its cousins in other disciplines. It might be worthwhile to examine the concept's relationship to Philosophy of Science, specifically Aristotelian Ontology/Taxonomy.
• Examples. This is a great opportunity for self referential humor that demonstrates correct (elucidating) or misleading (occult) use of the term. Some links should be footnotes in this section.
• Related Concepts. Links to other stuff that does not belong IN, just NEAR this page: Although I'm fond of citing Godel's Theorem on Incompleteness, it's only a tangent on the basis that complexity prevents any system of abstractions from being complete. It does not explain "Law of Leaky Abstractions." These links should be a list of relationship descriptions, not just a list of related items: the verbs AND the nouns of the relationship. This makes room for all of the other big ideas people usually want to lump into the article.

I'm in favor of wiping the article and starting over. In cases of an edit war, and reading this talk page, no lack of energy can be blamed for the relative completeness or correctness. Let go. Use the force!

What say ye, Wikipedians?

aphor (talk) 16:59, 11 December 2009 (UTC)

Added some citations. In lieu of other contributors, the current article can be a placeholder for the one you envision. Pax vobiscum. --Ancheta Wis (talk) 11:06, 3 February 2010 (UTC)

The question is this: one article titled "Leaky Abstraction" which refers to "The Law of Leaky Abstractions" in its Etymology section? Or a "The Law of Leaky Abstractions" article which talks about Spolsky's paper and its effects? Or both?206.124.141.187 (talk) 06:00, 2 April 2010 (UTC)

Rewriting system

In Lakatos, cited in the article, the Euler formula, also called the Euler characteristic is the toy problem which had tons of counterexamples (i.e., leaks) after a century of research. Poincare proves (i.e., implements) it by rewriting it in terms of another theory (a new dominant theory). There are articles on Rewriting systems which could be applied here. My point is there are many layers of abstraction which can potentially solve other problems (including leaks) at other layers of abstraction by rewriting (that is, refactoring). --Ancheta Wis (talk) 11:16, 3 February 2010 (UTC)

Time for a rewrite

It is interesting how many times folks have suggested that this page should be rewritten from scratch and apparently how few folks have tried to actually do it. Now that the edit war appears to have abated, I will take the opportunity to actually edit this page to reflect Wikipedia policies. Nickmalik (talk) 04:28, 23 September 2010 (UTC)

Spolsky is certainly not the first to use this term!!!

I usually don't bother to correct buggy Wikipedia articles, but this one struck a nerve as I recall discussing the concept of leaky abstractions with colleagues back in the 90's. I'm sure Spolsky is a great person but giving him credit for coming up with this term is certainly wrong.

Here is an earlier quotation:

"Inheritance has a touch of leaky abstraction about it because it is of the essence that it does not directly reveal what is being inherited except by its effects."

Here is the citation:

TY - JOUR

AU - Barnes, John

TI - Half a century of programming and not much progress

JO - Software Focus

JA - Softw. Focus

VL - 2

IS - 1

PB - John Wiley & Sons, Ltd.

SN - 1529-7950

UR - http://dx.doi.org/10.1002/swf.24

DO - 10.1002/swf.24

SP - 15

EP - 20

KW - software programming

KW - programming languages

KW - complexity

KW - abstraction

PY - 2001

ER -

http://onlinelibrary.wiley.com/doi/10.1002/swf.24/full

Note that the author of this article uses the term "leaky abstraction" as if he expects the reader to be familiar with it.

130.238.11.75 (talk) 10:35, 1 November 2011 (UTC)

Time to retire this page

This has been a controversial page because of its title: "Leaky abstraction". The term is a piece of jargon, and describing the colloquial use of jargon is not the role of Wikipedia.

There's even controversy about the origin of the phrase. There's strong evidence that it wasn't coined by Spolsky.

I propose renaming this article "Law of Leaky Abstractions", which is a concrete thesis put forward by Spolsky, and which can be described objectively by reference to Spolsky's paper. (I believe it would still be appropriate to cite known and clear antecedents to the paper, such as Barnes's and Kiczales's.)

This page can be turned into a redirect to "Law of Leaky Abstractions".

The "Effect on Software Development" section should be deleted as original pontification.

206.124.141.187 (talk) 08:26, 7 December 2012 (UTC)

State of the page: leakiness probably unavoidable

I see some old discussions above, but my impression is that the state of this article is reasonable: some leakiness seems unavoidable. A reader unfamiliar with the specific programming examples would have difficulty following them without continuing through to the related Wikipedia articles or trying the actual coding, but that seems difficult to avoid. A Wikipedia article should be an abstraction, but typically cannot avoid being leaky for in-depth understanding. That's the nature of knowledge - deeply interconnected.

Any specific proposals for improvement should of course be done by editing or proposing edits on the talk page. :) Boud (talk) 18:14, 28 September 2023 (UTC)