[dead]
That's not an abstraction, that's a layer of indirection
21–30 of 240 posts
Re: That's not an abstraction, that's a layer of indirection
#22How did "abstraction" and "hiding complexity" become perceived as such fundamental virtues in software development? There are actual virtues in that ballpark - reusable, reliable, flexible - but creating abstractions and hiding complexity does not necessarily lead to these virtues. Abstraction sounds no more virtuous to me than indirection.
>How did "abstraction" and "hiding complexity" become perceived as such fundamental virtues in software development?
They aren't just fundamental virtues in software development, they're the fundamental basis of all cognition. If I twiddled with every bit in my computer I'd never write a hello world program, if I wrestled with every atom in my coffee cup I'd never drink a sip of coffee.
Abstraction and information hiding is the only way we ever accomplish anything because the amount of information fitting in our heads is astonishingly small compared to the systems we build. Without systems of abstraction we would literally get nothing meaningful done.
Re: That's not an abstraction, that's a layer of indirection
#23Re: That's not an abstraction, that's a layer of indirection
#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.
Re: That's not an abstraction, that's a layer of indirection
#25I 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 code, I can see a lot of times I tried to abstract away display code in ways that made it exceedingly difficult to detect why it only failed on certain pieces of data. Sometimes this was sheep shaving tightly bound code into generic routines, and sometimes it was planned that way. This is another type of abstraction that adds cognitive load: One where instead of writing wrappers for a specific use case, you try to generalize everything you write to account for all possible use cases in advance.
There's some sort of balance that has to be struck between these two poles. The older I get, though, the more I suspect that whatever balance I strike today I'll find unsatisfactory if I have to revisit the code in ten years.
Re: That's not an abstraction, that's a layer of indirection
#26I 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…
Ahh yes, the labor of love that is code maintenance.
Done is better than perfect until you’re reviewing the code in 10 years (or maybe 3 years with a more adept set of eyes over your shoulders).
These days I ask my teams to be less clever and more simple.
Simple usually wins over clever in the long run.
Re: That's not an abstraction, that's a layer of indirection
#27I wish this article had more examples/details; as it is, it is kind of .. abstract
Re: That's not an abstraction, that's a layer of indirection
#28Perhaps 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…
“The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” — Edsger Dijkstra But sometimes a new semantic level isn’t needed. Abstraction gets so much press when you might just need some good ol’ fashioned information hiding and separation of concerns.
This is such a great quote, and helps explain what is a good abstraction.
Because CRDTs have been in the zeitgeist a lot lately, I want to pick them as an example of a "good" abstraction.
CRDTs have mathematical properties which can be described and understood independently of a specific implementation. And importantly, you can judge whether an implementation is correct with reference to these abstract rules.
This means that when using a CRDT, you largely can treat it as a reliably-solved problem. Once you understand the concepts, and work out how to use the library you've picked, you don't have to think about the details. Though that doesn't mean sometimes the behaviour can be surprising:
https://www.moment.dev/blog/lies-i-was-told-pt-1
TCP and HTTP are great examples too, though interestingly I don't know if they rely on mathematical definitions so much as just being extremely widespread to the point that reliable implementations are available anywhere you care to write code.
I like this article which also leans on the Dijkstra quote:
https://www.pathsensitive.com/2022/03/abstraction-not-what-y...
Re: That's not an abstraction, that's a layer of indirection
#29I 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…
I learned that lesson building an utility with JavaFX. I've done a few years with React and the usual pattern was to move almost everything out of the components. Unless it's an event handler, a data transformer for the view, or something that manipulates the view, it has no business belonging to this layer.
I don't try to generalize it, I just try to make the separation clear using functions/methods/classes. Instead of having the post button's handler directly send the request, I create a function inside the `api` module that does it. It does have the effect on putting names on code patterns inside the project.
Re: That's not an abstraction, that's a layer of indirection
#30>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.
This has such potential to be an interesting thread of conversation but all I get is a reference to a book that I haven't read and am unlikely to.
What examples of non-leaky abstractions do you have?
I could imagine something like "newtonian physics" but that leaks into my daily life every time I fire up google maps and get a GPS fix.
The OP's example of TCP seems close to the mark, but to be totally honest I'm not convinced. Every time I have to run ping to check whether my hung connection is due to connectivity, I'm breaking the abstraction. And I've had to debug network issues with Ethereal (yes, I'm dating myself). TCP does leak, it's just that most people don't know what to do with it when it does.