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

51–60 of 93 posts

Re: The Law of Leaky Abstractions (2002)

#51

Post by avgcorrection »

samatman wrote: post #42
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…

> There are leaky abstractions I guess but not all are. A garbage collector that can cause memory errors would be leaky. I don’t know anything about garbage collectors but in my experience they don’t. Garbage collectors are a rich source of abstraction leaks, depending on what you do with the runtime. If you color within the lines, no surprises, the garbage collector will work. Unless it has a bug, and hundreds of GC…

> But go ahead and use the FFI and things aren't so rosy. Usually the GC can cooperate with allocated memory from the other side of the FFI, but this requires care and attention to detail, or you get memory bugs, and just like that, you're manually managing memory in a garbage collected language, and you can segfault on a use-after-free just like a Real Programmer.

Now you’ve stepped beyond the walled gardens of the managed memory. How is that an abstraction leak?

> It's also quite plausible to write a program in a GC language which leaks memory, by accidentally retaining a reference to something which you thought you'd deleted the last reference to.

That the user just thought they had gotten rid of? If the memory is technically reachable then that doesn’t sound like its fault. I’m reminded of the recent Rust Vec thread on how the so-called space leak of reusing allocated memory lead to unreasonable memory consumption. But to my recollection that wasn’t a leak in the sense of unreachable-but-not-freed. I do agree however (with those that made this point) that the Vec behavior was too clever. Which goes to show that Vec should probably just stick to the front-page abstraction advertised: will amortize allocations, can shrink to fit if you tell it to, nothing much more fancy beyond that.

(The memory leak topic seems very fuzzy in general.)

Re: The Law of Leaky Abstractions (2002)

#52

Post by yen223 »

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…

There's a well-written article by Bret Victor on climbing the ladder of abstraction. It makes the same argument you made, in that climbing "down" the ladder is just as important as going "up"

https://worrydream.com/LadderOfAbstraction/

Re: The Law of Leaky Abstractions (2002)

#53

Post by ufo »

cloogshicer wrote: post #48
eschneider wrote: post #30

Earlier quoted context omitted.

That's not really true of, at least C compilers. Because compilers have ABI's and fixed calling conventions, it's straightforward, documented, and not uncommon (depending on your application area/deployment target) to drop down to the ASM layer if you need to do that. It's definitely one of those things that makes C nice for bare metal programming.

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 step on your toes.

Re: The Law of Leaky Abstractions (2002)

#54

Post by cloogshicer »

yen223 wrote: post #52
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…

There's a well-written article by Bret Victor on climbing the ladder of abstraction. It makes the same argument you made, in that climbing "down" the ladder is just as important as going "up" https://worrydream.com/LadderOfAbstraction/

Thank you for posting, I love that article. Bret Victor is a genius in my opinion and his writings and talks have inspired many of the thoughts I've written above.

Re: The Law of Leaky Abstractions (2002)

#55

Post by bxparks »

avgcorrection wrote: post #18
bxparks wrote: post #16

Earlier quoted context omitted.

I unflagged you by vouching for you. I found your post difficult to understand and couldn't figure out what you are trying to say, but I agree it was not deserving of a flag.

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 answers but not obvious to me, terms that aren't clear (e.g. what is an "amortized push"?), and concepts that don't seem to be related to GC (e.g. an "abstract list" can be implemented without GC, so why is that included in that paragraph?).

I've read those paragraphs 4-5 times now, and I don't think I understand what you are trying to say.

Re: The Law of Leaky Abstractions (2002)

#57

Post by lmm »

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 tuning manually (indeed PostgreSQL doesn't even offer you the ability to do hints etc., and that doesn't seem to hurt its popularity). I've never understood why this post was so popular - it only ever seems to be used as an excuse for those who want to write bad code to do so.

Re: The Law of Leaky Abstractions (2002)

#58

Post by rancour »

samatman wrote: post #33
refactor_master wrote: post #31

A car is an implementation meant to deal with a problem (the weather), but never abstracts away physics or forces full buy-in to some alternate reality. You can’t just go around and say any imperfection in an implementation is a leaky abstraction. That’s not how it works. My shoe is not abstracting away the terrain, nor is it leaky because it doesn’t handle all weather conditions. Well, it is leaky, but not in that s…

An analogy is an abstraction, and abstractions leak.

[dead]

Re: The Law of Leaky Abstractions (2002)

#60

Post by lmm »

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…

The best paradigm for understanding abstractions is not the theory-and-model style (which requires hiding details irreversibly), but the equivalence style.

A good abstraction is e.g. summing a list whose elements are a monoid - summing the list is equivalent to adding up all the elements in a loop. Crucially, this doesn't require you to "forget" the specific type of element that your list has - a bad version of this library would say that your list elements have to be subtypes of some "number" type and the sum of your list came back as a "number", permanently destroying the details of the specific type that it actually is. But with the monoid model your "sum" is still whatever complex type you wanted it to be - you've just summed it up in the way appropriate to that type.

Post reply on HN