It seems like you missed the point the article was trying to make: an abstraction is a mapping from a complex world to a simpler world, which preserves the ability to perform many useful operations.
Data structures can be used as part of an abstraction. So can functions. But neither one is the abstraction.
In the case of data structures, you might use a particular data-structure as the domain of the simpler world, but it's the mapping itself that is the abstraction, and that mapping is not part of the code, it's a conceptual thing that must be documented.
All of those quotes say how important data and its representation is to a programmer, but that doesn't equate to saying data structures are abstractions, because abstractions aren't the only important thing. I'm not sure they're even the most important thing.
You could say that an abstraction is a decision about which details of the complex world are important, or even expressible. Problems are sometimes intractable just because the wrong decision's been made.
My feeling is that abstractions can also be (potentially) more. E.g. good abstractions are themselves composable in expressive and new ways, which gives programmers the ability to reach goals faster, easier and with less risk and maintenance cost.
Building abstractions can be ery much like creating a new language.
Still, I bet Laplace's demon could get by just fine without them, and maybe even spot clever optimizations that a human never would. After all, there's no such thing as a free lunch.
> After all, there's no such thing as a free lunch.
I think a lot depends on where your cost goes. E.g. you could create hyper-optimized code that performs incredibly well, but it is also hard to maintain, next to impossible to comprehend and cannot adapt to change very well.
I believe it is possible to create code that does well on all fronts (readable, maintainable, adaptable, performant), it is just a much harder search task (you pay it with developer time/experience).
Hm, every abstraction comes with costs and benefits. For information theoretic reasons ("no free lunch folklore"), the costs can never be completely eliminated.
The usual way to make abstractions useful is to choose a restricted problem space, compressible enough to offset the abstraction's overhead.
Data structures can be used as part of an abstraction. So can functions. But neither one is the abstraction.
In the case of data structures, you might use a particular data-structure as the domain of the simpler world, but it's the mapping itself that is the abstraction, and that mapping is not part of the code, it's a conceptual thing that must be documented.
All of those quotes say how important data and its representation is to a programmer, but that doesn't equate to saying data structures are abstractions, because abstractions aren't the only important thing. I'm not sure they're even the most important thing.