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

That's not an abstraction, that's a layer of indirection

fhur.me

Post reply on HN
Print view View original

101–110 of 240 posts

Re: That's not an abstraction, that's a layer of indirection

#101

Post by Jaxan »

anonytrary wrote: post #64

I'm not sure what it's called (abstraction vs. indirection) but I dislike when everything needs a class/object with some odd combination of curried functions. Some programming languages force this on you more than others I think? As a contrived example "StringManager.SlicingManager.sliceStringMaker(0)(24)(myStr)", I've seen code that reminds me of this and wonder why anyone uses a language where this not only an acce…

In Haskell gMaker(0)(24)(myStr) and gMaker(0, 24, myStr) would have the same syntax, namely gMaker 0 24 myStr. So that solves the issue.

Re: That's not an abstraction, that's a layer of indirection

#102

Post by mrcsd »

Garlef wrote: post #97

Wow... That was a lot of text without much depth to it. [Edit] To make my criticism more precise: The text mostly rephrases it's central point a few times and presents these rephrasings as arguments.

Funnily enough, logical deductions or formal theorem proofs can be seen as a set of transformative steps from the initial premises to the conclusion, where no new information is added in the process. Which makes the conclusion (at a stretch) a bit like "just" rephrasing the initial premises.

Re: That's not an abstraction, that's a layer of indirection

#103

Post by lelanthran »

VirusNewbie wrote: post #24

>There’s a well-known saying: "All abstractions leak." It’s true. No matter how good the abstraction, eventually, you’ll run into situations where you need to understand the underlying implementation details This is false. One can read up on Theorem's for Free by Wadler to see that not all abstractions are leaky.

"All abstractions are leaky, but some are useful" - me.

In fact, my own framework for small LoB webapps is based entirely around this premise.

Re: That's not an abstraction, that's a layer of indirection

#104

Post by mattmanser »

zelphirkalt wrote: post #98
astrobe_ wrote: post #79

Earlier quoted context omitted.

Yes, abstraction and generalization are properties you'd rather look for the second time around . Someone was already warning about this 25 years ago [1]: You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the…

Although of course solving the abstract problem does not have to be 10 times as much code. The best solutions are often those, that recognize the more general problem, solve it with little and elegant code, then turn to the specific problem, expressing it in terms of the abstract problem and thereby solving it in just a few lines of code. Such an approach should usually be accompanied by some documentation. To give a…

No. Just no.

This is the exact thought process that leads to unnecessary abstraction. This is the attitude that the article is criticizing.

A good rule of thumb is never abstract unless you genuinely have done the same thing twice already.

i.e. only write an abstraction after you've written the boring, simple, concrete, implementation twice and are about to write it a third time.

Re: That's not an abstraction, that's a layer of indirection

#105

Post by mrcsd »

Just thinking on my feet as to how I separate abstractions from indirections and it seems to me that there's a relatively decent rule of thumb to distinguish them: When layer A of code wraps layer B, then there are a few cases:

    1) If A is functionally identical to B, then A is a layer of indirection
    2) If A is functionally distinct from B, then A is likely an abstraction
    3) If A is functionally distinct from B, but B must be considered when 
       handling A, then A is a leaky abstraction.
The idea is that we try to identify layers of indirection by the fact that they don't provide any functional "value".

Re: That's not an abstraction, that's a layer of indirection

#106

Post by nwmcsween »

The goal of an abstraction should be to make reasoning about the code easier, generally that means hiding complexity but that shouldn't be the goal.

In my opinion a common issue in programming is premature abstraction without understanding the interactions as a whole.

Re: That's not an abstraction, that's a layer of indirection

#107

Post by ramblerman »

noduerme wrote: post #25

I got a piece of advice writing UI code a long time ago: Don't marry your display code to your business logic. I'd like to say this has served me well. It's the reason I never went for JSX or other frameworks that put logical code into templates or things like that. That is one abstraction I found unhelpful. However, I've come around to not taking that advice as literally as I used to. Looking back over 25 years of c…

> Don't marry your display code to your business logic.

> It's the reason I never went for JSX or other frameworks that put logical code into templates or things like that

That's not mixing business logic with display code, your confusing (or conflating) 2 entirely different things here.

Re: That's not an abstraction, that's a layer of indirection

#108

Post by scotty79 »

mrcsd wrote: post #102
Garlef wrote: post #97

Wow... That was a lot of text without much depth to it. [Edit] To make my criticism more precise: The text mostly rephrases it's central point a few times and presents these rephrasings as arguments.

Funnily enough, logical deductions or formal theorem proofs can be seen as a set of transformative steps from the initial premises to the conclusion, where no new information is added in the process. Which makes the conclusion (at a stretch) a bit like "just" rephrasing the initial premises.

Not really. Usually during the deduction you have some steps that pull surprising knowledge from the rest of math to support the reasoning or create and prove interesting lemmas.

If you can prove a theorem without any of that, that's a little boring theorem to prove.

Re: That's not an abstraction, that's a layer of indirection

#109

Post by ordu »

Voultapher wrote: post #92

> That’s the sign of a great abstraction. It allows us to operate as if the underlying complexity simply doesn't exist. While I generally agree with the sentiment that current day software development is too indirection heavy, I'm not sure I agree with that point. All abstractions are leaky and sure good abstractions allow you to treat it like a black box, but at some point you'd benefit from knowing how the sauce is…

It is funnily recursive...

I'll try to explain, but I'm not sure my English is good enough for that task. But lets try.

When the author says "great abstraction" they mean "ideal abstraction". You can see this for example in this quote: " The less often you need to break the illusion, the better the abstraction." They say even the phrase "all abstractions leak", which is the main point of yours.

So, if they mean an "ideal abstraction", what does it mean? What it means to be ideal? It means to be an imagined entity with all sharp corners removed. The idea of "ideal" I believe is an invention of Ancient Greeks, and all their art and philosophy were built around them. Their geometry was an ideal thing, that doesn't really exist anywhere except the brains of a mathematician. Any ideal thing is not real by the definition.

Why to invent ideals? To simplify thinking about real entities and talking about them. They allow us to ignore a lot of complicating details to concentrate on the essence. So it is like an abstraction, just not for programming but for thinking, isn't it?

And now we come to the recursion. The author used abstraction over abstraction to talk about abstractions, and you used built-in deficiency of all abstractions (they are not real) to attack the abstraction over abstraction.

Somehow it not as funny as I felt first, but still...

Re: That's not an abstraction, that's a layer of indirection

#110

Post by dustingetz »

astrobe_ wrote: post #79
voidhorse wrote: post #43

The best way to achieve a good abstraction is to recall what the word meant before computer science: namely, something closer to generalization . In computing, we emphasize the communicational (i.e. interface) aspects of our code, and, in this respect, tend to focus on an "abstraction"'s role in hiding information. But a good abstraction does more than simply hide detail, it generalizes particulars into a new kind of…

Yes, abstraction and generalization are properties you'd rather look for the second time around . Someone was already warning about this 25 years ago [1]: You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the…

imo more like the 50th time around, and by a computer scientist, and not on company time until after the abstraction POC is validated, for example both React and Angular were side projects before the firm decided to invest. Software development outcomes today are driven by: ignorance, narcissism, and self preservation
Post reply on HN