Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Law of Leaky Abstractions (2002)

joelonsoftware.com

Post reply on HN
Print view View original

71–80 of 93 posts

Re: The Law of Leaky Abstractions (2002)

#71

Post by s_m_t »

jfoutz wrote: post #61
cloogshicer wrote: post #49

Earlier quoted context omitted.

> It is precisely those restrictions that bring the benefits [...] Wouldn't it be possible to say "ok, I'll take those restrictions as long as they benefit me, but once I notice that they no longer do, I'll break them and drop down to the lower layer. But only for those parts that actually require it"? > Abstractions necessarily involve being irreversible, or, to forestall a tedious discussion of the definition of "i…

I added 2 numbers and came up with 5. What numbers did I add? You can’t know, because the abstraction (add) destroys information. A “good “ abstraction destroys information that doesn’t matter, or maybe matter in a given context. You can hang on to all of that extra detail, but it seems like that extra detail slows down drawing inferences. When I claimed adding resulted in 5, you probably didn’t care if it was 5 appl…

I think there is something to the nature of your addition example that is counter to your point. Addition being an "abstraction" doesn't make it destroy information it's just an algebraic property of addition. If you instead took multiplication of prime numbers as your "abstraction", no less abstract than addition, then every product would have a unique factorization in the primes. Whether either of these operations makes sense for your problem and thus whether their limitations apply doesn't have anything to do with what "abstraction" you choose. They are either isomorphic to some aspect of your problem or they aren't.

Re: The Law of Leaky Abstractions (2002)

#72

Post by bombela »

bxparks wrote: post #55
avgcorrection wrote: post #18

Earlier quoted context omitted.

What was difficult about what I wrote?

Your criticism that a broken wire is outside the scope of the TCP protocol was clear and valid. The subsequent paragraphs about garage collection are tough to follow. You have multiple parenthetical remarks, a quotation which I think is used as emphasis, italics used as emphasis, compound sentence fragments joined by an em-dash and a colon in the same sentence, rhetorical questions which presumably have obvious answe…

amortized push: a fundamental data structure, the vector, is a growable array of elements. The standard name for the function that appends an element at the end of the array is "push". You push to the array.

A vector points to an allocated portion of memory. When full, a new one; usually double the size; is allocated, everything copied over, and the original allocation is discarded.

Therefore the cost of memory allocation and copy is amortized over many pushs.

Re: The Law of Leaky Abstractions (2002)

#74

Post by glial »

mturmon wrote: post #37
glial wrote: post #19

This is well-written. I might suggest that what makes pure mathematics special is that abstractions in pure math are not leaky, unlike in (nearly?) every other domain.

Didn't downvote, don't entirely disagree, but maybe it would be OK to say that the leaks can be made more apparent: "The integral reverses the derivative" † ‡ * † Up to an arbitrary additive constant ‡ Provided the derivative exists * And we hope you don't have concerns about the existence of the real numbers

True; I was thinking about abstract algebra, set theory, and number theory when I wrote that.

Re: The Law of Leaky Abstractions (2002)

#75

Post by ulbu »

jfoutz wrote: post #61
cloogshicer wrote: post #49

Earlier quoted context omitted.

> It is precisely those restrictions that bring the benefits [...] Wouldn't it be possible to say "ok, I'll take those restrictions as long as they benefit me, but once I notice that they no longer do, I'll break them and drop down to the lower layer. But only for those parts that actually require it"? > Abstractions necessarily involve being irreversible, or, to forestall a tedious discussion of the definition of "i…

I added 2 numbers and came up with 5. What numbers did I add? You can’t know, because the abstraction (add) destroys information. A “good “ abstraction destroys information that doesn’t matter, or maybe matter in a given context. You can hang on to all of that extra detail, but it seems like that extra detail slows down drawing inferences. When I claimed adding resulted in 5, you probably didn’t care if it was 5 appl…

You are right.

How Aristotle illustrated abstraction – by extracting the definition of triangle. Reversible abstraction would mean the possibility of taking a triangle in the Cartesian space and reconstructing the actual object that includes an instance of this triangle. We’d have to be able to reconstruct its material properties.

It is precisely this impossibility that is essential to abstraction. It involves the removal of properties of a particular to arrive at the abstract – the common, the universal.

Now, it is possible to arrive at a poor, incomplete abstraction. Imagine if we dealt with red triangles and green triangles, as opposed to just triangles. If we wished to operate on the its underlying triangle, we would have to remove the colour at each operation. It would be an unused variable. We don’t want that – so we remove the property of colour from our triangle operations entirely. And thatbis the only way to deal with triangles.

Reversibility is simply a different property that can’t be attached to abstraction is if we wish precision at all.

Re: The Law of Leaky Abstractions (2002)

#76

Post by falserum »

lmm wrote: post #57

This is wrong and even just looking at the examples is enough to understand that it's wrong. Writing your program to use UDP instead of TCP won't make it work any better when someone unplugs the network cable. An abstraction performing worse isn't a "leak" - the abstraction is still doing what it said it would (e.g. the SQL query still returns the right results), and in practice very few query planners are worth tuni…

> Writing your program to use UDP instead of TCP won't make it …

There was no proposal to use UDP, so this comment is not about the article.

The point of the article is near the end:

> the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning.

I.e. To competently use an abstraction, one needs to understand what happens under the hood.

Re: The Law of Leaky Abstractions (2002)

#78

Post by falserum »

avgcorrection wrote: post #5

> Back to TCP. Earlier for the sake of simplicity I told a little fib, and some of you have steam coming out of your ears by now because this fib is driving you crazy. I said that TCP guarantees that your message will arrive. It doesn’t, actually. If your pet snake has chewed through the network cable leading to your computer, and no IP packets can get through, then TCP can’t do anything about it and your message doe…

Seems like you missed the point of the article.

Yes, most of the article is dedicated to describe the “leak”, but there was no call to abolish abstractions. Just the insight that one needs to understand implementation of those.

Re: The Law of Leaky Abstractions (2002)

#79

Post by cloogshicer »

saghm wrote: post #63
cloogshicer wrote: post #24

I've long been having a hunch that we're currently in the "wild west of abstraction". I think we're missing an essential constraint on the way we do abstraction. My hunch is that this constraint should be that abstractions must be reversible. Here's an example: When you use a compiler, you can work at a higher layer of abstraction (the higher-level language). But, this means you're now locked into that layer of abstr…

> My hunch is that this constraint should be that abstractions must be reversible. > Here's an example: When you use a compiler, you can work at a higher layer of abstraction (the higher-level language). But, this means you're now locked into that layer of abstraction. By that I mean, you can no longer work at the lower layer (assembly), even if you wanted to. You could in theory of course modify the compiler output…

Yes, you understood correctly.

What I'm saying is extremely radical and would require rethinking and rebuilding practically everything we have.

Re: The Law of Leaky Abstractions (2002)

#80

Post by cloogshicer »

ufo wrote: post #53
cloogshicer wrote: post #48

Earlier quoted context omitted.

Interesting, I'm curious though, once you do drop down to the ASM layer, how do you ensure that this code doesn't get overwritten by new compiler output? Or is this something you somehow include in the compile step?

Typically you'd have some assembly functions in a separate file. Compile to an object file and link it, as you'd do with a separate C file. If you want to insert assembly snippets inside a C function, many C compilers have an inline assembly feature. For simple snippets, the C compiler can figure it out. For more complex things, you there are ways to tell the C compilers which registers you're using, so it does not s…

Thank you for explaining!
Post reply on HN