Abstract vs. General
The word “abstract” is probably one of the most convoluted out there. Ironically, one of the meanings is “an opposite of concrete”, so it is somehow convoluted by definition.
Anyway, there are “abstract paintings”, abstractionism in general, “abstract mathematics” and even “abstract thinking”, which is, by definition, a synonim for a bullshit.
In addition to that we have “Abstract Data Types”, which, ironically, a very “concrete”, almost mathematical notion.
There is something called the Set Abstraction – how the abstract notion of a Set is defined in terms of a (another) set of possible operations. The notion of a Set is captured by a set of possible operations.
The point is that we have to stop calling everything an abstraction (or abstract) and use more precise, “more concrete” notions.
Let’s say we observe a reccurent pattern, or we observe a commonality (a “common pattern” is an abuse of a language).
Whan can we do with an observation? We could “abstract out” or “generalize” and these are not the same thing.
We say that we “abstract out a common pattern” (should be “common traits”) and we “generalize a reccurent pattern”.
By abstracting out we usually mean creating a new concept (or a corresponding type). By generalizing we mean some factoring out of what is common (the same) and (together with) a paramterization of what is specific (different).
It turns out we used to call very different processes by the same abstract term “absraction”, and this is only the beginning of the story.
At an intuitive level, we abstract away (or out) by introducing a new type and we generalize by factoring out commonalities and parameterizing with varying specifics.
B. Liskov
What Barbra Liskov called “procedural abstraction” is the notion of hidding the implementation details and threating the procedure as a “black box”.
She got her Turing Award for a reason. She successfuly captured and formally defined the very essence of programming – the necessity of having and thinking in terms of “black boxes”, and how to specify them using abstract interfaces and (together with) formal specifications.
Just like Sets.
Having this, a higher level notion of an “abstration by specification” naturally follows, when we think (and know) a procedure by its interface and its specification, not its implementation or even its algorithm.
Again, the abstract notion of a Mathematical Set is the canonical example. True mathematicians do not even bother with reoresentations, implementations or even existence of their abstrations. Only we do.
Mathematicians define a set of operations on sets and thus define what a Set is.
In our terminology an abstract data type of a Mathmatical Set is defined in terms of /abstract interfaces – function type-signatures inside an isolated module. Nothing is abstract there.
Look ma, no classes or objects
Notice that no objects (with an “encapsulared internal state”) are required. Values and functions as “black-box abstractions”. Here it means that “concrete” details are deliberately abstracted away.
The fact that values, types as constrained subsets of values, functions, interfaces (type-signatures) and modules (as well as type-classes or traits) are good-enough for everything is a profound realization.