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

61–70 of 93 posts

Re: The Law of Leaky Abstractions (2002)

#61

Post by jfoutz »

cloogshicer wrote: post #49
jerf wrote: post #34

Earlier quoted context omitted.

Abstractions work by restricting the domain of what you can do, then building on those restrictions. For example, raw hardware can jump anywhere, but structured programming constrains you to jump only to certain locations in order to implement if, for, functions, etc. It is precisely those restrictions that bring the benefits of structured programming; if you still frequently dipped into jumping around directly struc…

> 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 apples or 5 skyscrapers. The addition results of 5 are the important part.

Kinda hand waving, but what is included and what is left out is the heart of abstraction imho. And when it’s left out, you can’t get it back.

Re: The Law of Leaky Abstractions (2002)

#63

Post by saghm »

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 after it's been generated, but then you'd have to somehow manually keep that work in sync whenever you want to re-generate. Using an abstraction kinda locks you into that layer.

Just to make sure I understand, you're proposing a constraint that would rule out every compiler in existence today? I feel like overall I think compilers have worked out well, but if I'm not misunderstanding and this is how you actually feel, I guess I at least should comment your audacity, because I don't think I'd be willing to seriously propose something that radical.

Re: The Law of Leaky Abstractions (2002)

#64

Post by [deleted] »

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…

[deleted]

Re: The Law of Leaky Abstractions (2002)

#65

Post by yogorenapan »

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…

A lot of languages allow in-line assembly

Re: The Law of Leaky Abstractions (2002)

#66

Post by Legend2440 »

williamcotton wrote: post #35
Legend2440 wrote: post #17

Earlier quoted context omitted.

Worse; it's a stack of abstractions on top of abstractions on top of abstractions. You're at least 10 layers away from the hardware, possibly more.

I don’t necessarily see that as the problem. Assembly is a great abstraction over machine code. Languages that compile to these bytecodes are a good abstraction. Garbage collected languages are a good abstraction. Web applications are not a good abstraction. Auth, storage, route handlers, tests, deployment, et al, are all cobbled together like chocolate ice cream and jalapeños on an uncooked bed of salmon and root be…

It's not necessarily a problem. It would be very hard to program without abstractions.

But all abstraction is compression in a sense. You are writing a smaller program that is "decompressed" into a much larger compute graph - for example, a loop unrolls into the same operation many times. This makes it much easier to fit the program into your head, but also limits its complexity.

This is why it's hard for programs to deal with the arbitrarily-complex real world.

Re: The Law of Leaky Abstractions (2002)

#67

Post by williamcotton »

Legend2440 wrote: post #66
williamcotton wrote: post #35

Earlier quoted context omitted.

I don’t necessarily see that as the problem. Assembly is a great abstraction over machine code. Languages that compile to these bytecodes are a good abstraction. Garbage collected languages are a good abstraction. Web applications are not a good abstraction. Auth, storage, route handlers, tests, deployment, et al, are all cobbled together like chocolate ice cream and jalapeños on an uncooked bed of salmon and root be…

It's not necessarily a problem. It would be very hard to program without abstractions. But all abstraction is compression in a sense. You are writing a smaller program that is "decompressed" into a much larger compute graph - for example, a loop unrolls into the same operation many times. This makes it much easier to fit the program into your head, but also limits its complexity. This is why it's hard for programs to…

Arbitrarily complex domains are one thing. Arbitrarily complex web applications are another.

Re: The Law of Leaky Abstractions (2002)

#68

Post by saghm »

yogorenapan wrote: post #65
saghm wrote: post #63

Earlier quoted context omitted.

> 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…

A lot of languages allow in-line assembly

I'm repeating the claim that the parent comment made; the assertion that compilers lock you into a level of abstraction is theirs, not mine.

Re: The Law of Leaky Abstractions (2002)

#69

Post by foobarian »

> But sometimes the abstraction leaks and causes horrible performance and you have to break out the query plan analyzer and study what it did wrong, and figure out how to make your query run faster

Hah. The more things change, the more they stay the same.

Re: The Law of Leaky Abstractions (2002)

#70

Post by __s »

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…

I think this is a good way to frame abstraction vs macro
Post reply on HN