Talk:Leaky abstraction

From Wikipedia, the free encyclopedia

[edit] 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)

[edit] 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)

[edit] 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:

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)