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.
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...
I wrote this [0] previously, but it still applies. IMO, as a dev, there are times where you really do need to think somewhat deeply about infrastructure choices. Unfortunately, knowing when you need to care practically requires you to already understand it.
that's exactly what you do to implement an abstraction isnt it?
That you used wood doesn’t mean you built a house.
Indirection is about providing a common language, and interface if you will, for talking to different implementations.
Separating concerns is another strategy altogether for managing resources.
In that sense, we can correctly say that even encapsulation etc is a form of (colloquial) abstraction, but not Dijkstra's use of the word abstraction.
On practice, there exist platonic abstractions that hide mechanisms and can be this way, but you also need to abstract parts of your requirements. And you will never be able to achieve that while abstracting your requirements.
Dijkstra was an academic after all, and academics usually don't care about complex requirements.