“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:
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:
CRDTs are also an excellent example because of how their supporting infrastructure is impacted by their design, namely that Postgres’ method of dealing with updates makes for massive write amplification.
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.
It seems like almost everybody in these comments as well as OP are failing to differentiate between the narrow computer science / Dijkstra definition of abstraction versus how it's invoked colloquially, including in conversations of computer science such as here.
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.
Maybe that’s the problem. Everyone knows that abstractions are desirable, and encapsulates as much as they can, and ends up with redirection hell without any of the advantages of true abstractions. If people understood what the word actually means, we might not be in this mess.
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.
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.