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