5 ms·

Basically functions are not abstractions, the data structures that functions act on are the real abstractions. Because the data structures have been planned out

by SPBS 5y ago

Basically functions are not abstractions, the data structures that functions act on are the real abstractions. Because the data structures have been planned out in a particular way, functions can manipulate them as if they were manipulating concrete entities in the business domain. Here's a bunch of relevant quotes talking about that idea (credits to https://medium.com/webdevops/data-structures-548cbea9c520 https://medium.com/webdevops/data-structures-548cbea9c520) "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." - 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." - https://www.cs.utah.edu/~germain/PPS/Topics/information_representation_and_transformations.html https://www.cs.utah.edu/~germain/PPS/Topics/information_repr...

lobstey 5y ago
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.
dgb23 5y ago
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
Diggsey 5y ago
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.
- macrolocal 5y ago
  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.
  - atoav 5y ago
    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.
    - macrolocal 5y ago
      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.
      - atoav 5y ago
        > 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).
        macrolocal 5y ago
        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.
mumblemumble 5y ago
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.)
dustingetz 5y ago
"What is "data" without an interpreter" - Alan Kay https://news.ycombinator.com/item?id=11946764 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
the_af 5y ago
> 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.
akomtu 5y ago
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.
- Koshkin 5y ago
  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.
  - all2 5y ago
    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]
tromp 5y ago
> the data structures that functions act on are the real abstractions I think type level functions, like Functor or Monad, also qualify as abstractions.
Hinrik 5y ago
"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)
jhgb 5y ago
> 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.
rajangdavis 5y ago
"It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." - Alan Perlis
proc0 5y ago
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.
amelius 5y ago
But if you're writing a compiler, the program becomes the data ...
postingposts 5y ago
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?
tome 5y ago
> - 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!

by SPBS 5y ago

lobstey 5y ago

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.

dgb23 5y ago

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

Diggsey 5y ago

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.

macrolocal 5y ago
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.
- atoav 5y ago
  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.
  - macrolocal 5y ago
    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.
    - atoav 5y ago
      > 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).
      - macrolocal 5y ago
        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.

mumblemumble 5y ago

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.)

dustingetz 5y ago

"What is "data" without an interpreter" - Alan Kay https://news.ycombinator.com/item?id=11946764 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

the_af 5y ago

> 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.

akomtu 5y ago

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.

Koshkin 5y ago
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.
- all2 5y ago
  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]

tromp 5y ago

> the data structures that functions act on are the real abstractions I think type level functions, like Functor or Monad, also qualify as abstractions.

Hinrik 5y ago

"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)

jhgb 5y ago

> 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.

rajangdavis 5y ago

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

proc0 5y ago

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.

amelius 5y ago

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

postingposts 5y ago

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?

tome 5y ago

> - 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!