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.

And then a lisp programmer parachutes in and points out that functions are absolutely a kind of data structure, other functions can act on them, and whether they're part of your business domain depends on how you've defined your business domain.

And then a data scientist with expertise in differentiable programming zooms in on a motorcycle to back them up.

And then a mathematician with expertise in linear algebra time travels in from the 19th century to join the party, although they're admittedly a bit lost and confused and not much help in this particular conversation because they're not familiar with modern jargon.

Which isn't to say that those quotes aren't valid or don't express concepts worth knowing and internalizing. But they're practical statements that apply to a certain way of looking at things. A very useful one, to be sure, but not the only one. The distinction between functions and data has a tendency to disappear upon close examination.

(Almost as if the concepts of "function" and "data structure" were themselves abstractions.)

Functions are abstractions in time; data structures are abstractions in space. For example, the same abstraction looks like binary search when drscribed as a function and it looks like a binary tree when described as a data structure. What binary search looks like by itself is unthinkable to us because anything we can think about has to be projected to space or time.

Edit. If the vertical axis is time and the horizontal plane is space, then the floating something in the middle is the 'abstraction', its shadow on the plane below is its data structure and its projection onto the vertical axis is its function. The need to compress everything into the 1-dimensional time is what creates those for-loops and ifs. The art of finding the right data structure is the art of finding the right angle at which the 'abstraction' drops a good descriptive shadow.

Computers indeed look more and more like black holes. It is not unexpected, then, that one feels the need now to talk about structurefunctions that live in spacetime.

We might call a structurefunction an object. Maybe if we made this programming paradigm object oriented we could solve some real-world problems.

[edit] spelling [/edit]

"What is "data" without an interpreter" - Alan Kay https://news.ycombinator.com/item?id=11946764

You've failed to account for the interpreter and the hardware it runs on that provides operational properties necessary for human use, i.e. performance

But this is more about shifting focus. You still need both, data and functions even if you make data richer and functions more general and simple. The latter still carry or encode an essential part about how you model information. Especially if we consider this quote here:

"Syntax without representation is tyranny!"

- Gerald Jay Sussman

Functions are abstractions of the business logic. If they weren't then you couldn't use them over and over again. It's abstracting by exposing a simple interface that then does more under the hood, and this is repeated layer after layer, from functions to libraries.

The decision of what a function will do over and over again is abstracting the layer below which if it weren't for the function, would have repetition of some kind. It's taking those repeated bits, and factoring out the different elements reducing them to a function call.

That said, I understand where this perspective is coming from, and perhaps "refinement" is more descriptive of a more practical approach.

"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)

> Basically functions are not abstractions, the data structures that functions act on are the real abstractions

That distinction sounds mildly problematic when one can turn a data structure into a function.

> - Linus Torvalds > > "Fold knowledge into data, so program logic can be stupid and robust." > > - Eric S. Raymond > > "Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." > > - Rob Pike > > "Representation is the Essence of Programming" > > - Fred Brooks > > "One of the key attributes of a "Good" representation, is the ease in which it is transformed into other valid information the computer can process."

Ah, they're advocates for strongly-typed programming and they didn't even know it!

> Basically functions are not abstractions, the data structures that functions act on are the real abstractions

Maybe, but this is not at all what the article is arguing, however.

Why don’t they define data structures if that’s so important? Lol. I get what they mean, but interpretation isn’t really a value in programming. Why not just explain it all the way?

"It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." - Alan Perlis

cannot agree on that. Here you got the OO ways of thinking by combining the data and code logic. However, it's totally legitimate to say functions wrapped up the procedures or transformations l.

But if you're writing a compiler, the program becomes the data ...

> the data structures that functions act on are the real abstractions

I think type level functions, like Functor or Monad, also qualify as abstractions.