> But we've had a pretty good definition of abstraction since 1977, originally in the context of program analysis, and — I claim — it actually translates quite well into a precise definition of “abstraction” in engineering.
So I don't think the author is saying that all these other people are "wrong", but rather that this one particular definition seems to capture the underlying essence of what we intuitively think of when we say "abstraction", and the rest of the "hodgepodge of different concepts" break down if you analyze them a bit deeper (as the author did in the "Not Abstraction" section).
Yes and I don't agree that this is particularly fruitful. I might have completely misunderstood it but here we go:
The common theme in the Not Abstraction section is: These things are used to build abstractions and are not necessarily abstractions themselves. This is not only nitpicking but it's also false. Programming language features like functions and interfaces are already abstractions, even in the narrow sense that the article describes. They are an idealized mapping to something concrete (register machines, vms etc.) and provide precision, soundness and are based on specification.
Again, I very much like the core idea presented here, but I think it is completely unnecessary to make the claims about what is and isn't "true" abstraction.
Take this quote:
"Abstractions are separate from the code, and even from the abstract domain. It does not make sense to say that the bookTable function or anything else in this file “is” the abstraction, (..)"
The function _is_ not the abstraction because abstractions are entirely conceptual? Is it a way to communicate an abstraction then? What about the actual machine code the compiler produces from that function, is there some abstraction?
None of this helps me. The interesting part is that code is used to model information, it's not the world itself or even tries to be.
Then this:
"Feel free to call numbers an abstraction of the hardware, but be prepared to switch to this precise terminology when there's tension on the horizon."
Simple abstractions that are not discussed are names and signs. These are abstractions in the very real sense and they are very simple on their own. But they are entirely contextual and are allowed to mean different things. For example the term "abstraction".
Let's design a system that allows us to run virtual computers on a single hardware platform. In some part of this system we need to map real hardware addresses to virtual ones in order to isolate the different virtual computers.
Now you might need a way to take a real, logical address to a memory location on this machine and get a virtual address. You might have to run this system on many different hardware platforms and you only know the platforms you will run on today (or the next few months). Almost without thinking about it you might choose to use a virtual method on a class to define a function signature for this operation. That way folks implementing this system for different hardware platforms can create a sub-class and fill in a concrete definition of the virtual method. Now users of the system can translate an address and don't have to think about the underlying hardware platform they're running on! Abstraction!
Only it's not an abstraction.
If you attempt to formalize what it means to map a hardware address to the virtual address you will find it quite difficult because your interface provides no information about hardware addresses. In other words the virtual method does not put in all of the details of the concrete implementation and so we cannot maintain an invariant in our specifications that would ensure that we only translate valid addresses, or that translation is deterministic -- properties that would be important for users of the abstraction to truly be able to ignore the underlying complex domain. If we could write such a specification for this virtual method though, it would be very complicated, and that is a good sign this is not a good abstraction.
Abstractions are often separate from the code because they're much more general than a single program. If we came up with a better abstraction in a formal logic like separation logic or using Hoare logic -- we might be able to prove that the properties we care about hold and therefore any program that implements this specification will have the same properties. And there might be several such programs!
So what industry programmers are often saying when they are talking about "abstraction" is "indirection and vagueness." What this article is trying to show is that we can give precise definitions to our abstractions so that we can build new _semantic_ layers that have precise meaning: when I translate a hardware address I get a valid, deterministic virtual address and nothing else.
These are very useful properties to have. And I rather use an abstraction where these properties hold, rather than one that just takes care of some plumbing. There is a qualitative difference here.
> But we've had a pretty good definition of abstraction since 1977, originally in the context of program analysis, and — I claim — it actually translates quite well into a precise definition of “abstraction” in engineering.
So I don't think the author is saying that all these other people are "wrong", but rather that this one particular definition seems to capture the underlying essence of what we intuitively think of when we say "abstraction", and the rest of the "hodgepodge of different concepts" break down if you analyze them a bit deeper (as the author did in the "Not Abstraction" section).