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

81–90 of 240 posts

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

#81

Post by danparsonson »

mgaunard wrote: post #75
danparsonson wrote: post #2

Perhaps this is a minor nitpick, but > Abstractions are also the enemy of simplicity. Each new abstraction is supposed to make things simpler—that’s the promise, right? Not exactly, no. The purpose of abstraction is to hide implementation detail, and thereby insulate one part of the codebase/application/system from variations in another. Graphics APIs for example - yes your code may be simpler for not having to deal…

That would be encapsulation, not abstraction.

I disagree; to save duplicating my other reply to a similar comment: https://news.ycombinator.com/item?id=42529743

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

#82

Post by astrobe_ »

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

Computers are to manipulate data. Data = representations = abstractions This article is so fundamentally lost that it forgets what computers are for. Computers exist to implement abstractions.

You are confusing too many things.

"10" is the representation of a data; "0xA" is another representation of the same data.

Not being able to touch something doesn't make it an abstraction. Light is not an abstraction, a contract is not an abstraction. 10 is not an abstraction, it is an ordinal [1].

"Isomorphism" is an abstraction. It doesn't name a particular data or value, but a class of functions that share common properties. A function template or functions written in a dynamically typed language can describe a particular group of isomorphism.

[1] https://en.wikipedia.org/wiki/Set-theoretic_definition_of_na...

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

#83

Post by patrulek »

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

Computers are to manipulate data. Data = representations = abstractions This article is so fundamentally lost that it forgets what computers are for. Computers exist to implement abstractions.

I kind of agree and i find that is why (other) abstractions should be created around data not around behaviours.

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

#84

Post by kristiandupont »

Indirection serves a purpose as well. One that is related to, but not the same as abstractions. When you add a layer of indirection, you make it easier to, say, delete or change every item X instead of iterating through everything.

Unnecessary or redundant levels of indirection are bad, just like unnecessary or wrong abstractions are. But when applied correctly, they are useful.

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

#85

Post by blue_pants »

cloogshicer wrote: post #68
Darmani wrote: post #32

TCP is great. Long chains of one-line functions that just permute the arguments really suck. These both get called abstraction, and yet they're quite different. But then you hear people describe abstraction ahem abstractly. "Abstraction lets you think at a higher level," "abstraction hides implementation detail," and it's clear that neither of those things are really abstractions. As the OP mentions, we have a great…

Hey Jimmy, I've read your comment and also your article in the past with great interest. This topic is absolutely fascinating to me. I just re-read your article but unfortunately I still struggle to really understand it. I believe you have a lot of experience in this, so I'd love to read a more dumbed down version of it with less math and references to PL concepts and more practical examples. Like, this piece of code…

Very interesting indeed. +1 for more explanations

For example, in the "TV -> serial number" abstraction, if I were to define only one operation (checking whether two TV's are the same), would it make it a good abstraction, as now it is both sound and precise?

And what are the practical benefits of using this definition of abstraction? Even if I were to accept this definition, my colleagues might not necessarily do the same, nor would the general programming community

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

#87

Post by lifeisstillgood »

I suggest there are three types of layer that one passes through

Abstraction - this thing of rare beauty

Decision - often confused for abstraction and wrapper, this is best thought of as a case statement in a function. They are wildly better in my opinion than lots of classes

Wrapper - either fluff like getters and setters or placeholders for later decisions (acceptable) or weird classes and instances that the language affords but tend to be confusing - what is called indirection in the article

Tools, utils, libraries - these are I classify as handles / affordances for other code to use - maybe they add layers but they add a single way in to the nice abstraction above.

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

#88

Post by usrusr »

voidhorse wrote: post #44
danparsonson wrote: post #2

Perhaps this is a minor nitpick, but > Abstractions are also the enemy of simplicity. Each new abstraction is supposed to make things simpler—that’s the promise, right? Not exactly, no. The purpose of abstraction is to hide implementation detail, and thereby insulate one part of the codebase/application/system from variations in another. Graphics APIs for example - yes your code may be simpler for not having to deal…

While this is how the term is often used, I think it's cavalier use of language and confuses abstraction for modularity , and this linguistic confusion is one of the reasons a lot of programmers write bad "abstractions". Organizing your code into components that are as independent as possible is a good practice and is the pursuit of modularity. A proper abstraction on the other hand, is a generalization that simplifi…

I don't like the mental image of layers. It's not wrong, but it's terribly inclusive of everything that is bad about bad abstractions. Even the worst abstractions will often look kind of nice from the layers angle.

I prefer the concept of orthogonality: you have an entire plane where your domain requirements can move in, but the way you make persistence reliable is completely orthogonal to that plane. It should be implemented in a way that does not change when, say, your customer account becomes a composite of of multiple identities. And neither should the way you organize UI components change, or your transportation tooling change. That entire transportation layer stack, from ethernet all the way up to your domain model generator of choice.

Did I say layers? Yeah, I did. You'll often see the orthogonal aspects themselves consisting of layers. But that's an implementation detail and those layers tend to be more pragmatic than dogmatic, as in the way TCP goes out of its way to avoid hiding any of the addressing of the underlying IP. TCP absolutely is a layer, but it has zero ambition to perhaps run on top of something other than IP, or hide differences between IPv4 and IPv6 from higher layers. It focuses on one thing, implementing streams on top of packets, again a problem nicely orthogonal to the problem of routing those packets (what IP does) or anything built on top of those streams.

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

#89

Post by globular-toast »

While I too like to marvel at the TCP/IP stack as an example of abstraction done right, it would be unwise to think an abstraction is only "good" if you get it right first time.

The real point of abstraction is to enable software that is adaptable. If you are ever sure you can write a program the first time and get it perfect then you don't need to bother with any of this thinking. We do that all the time when writing ad hoc scripts to do particular tasks. They do their job and that's that.

But if you ever think software will continue to be used then you can almost guarantee that it will need to change at some point. If it is just a tiny script it's no problem to write it again, but that's not going to be acceptable for larger programs.

So this necessarily means that some layer or layers of your well-architected application will have to change. That does not mean it was a bad abstraction.

Abstraction is not about hiding things, it's about building higher levels of language. It enables you to work on individual layers or components without breaking the rest of the system. It very much should not be hiding things, because those things are likely to need to change. The bits that really don't change much, like TCP, are rarely written into application code.

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

#90

Post by psychoslave »

The article seems to go with the premise that abstractions are most often carelessly introduced when there is an obvious alternative that is simpler and more performant.

Yes, abstractions have a cost that will accumulate as they are layered.

But simple elegant solutions are not free. They are hard to come with, so they often need large amount of dedication ahead of any coding. And as long as we don't deliver anything, we have no clue what actual requirements we miss in our assumptions.

The road to reach the nice simple solutions is more often than not to go through some some clunky ugly solutions.

So rather than to conclude with "before running to abstraction think wisely", I would rather recommend "run, and once you'll have some idea of what was the uncharted territory like, think about how to make it more practical for future walks."

Post reply on HN