Comrades, I wasn’t trying to say anything controversial. I noted that functional programming is not just a programming style like avoiding side effects in OOP. The definition of functions is closer to the sense in mathematics, with inputs and outputs.
Of course, anyone can use these words however they like. One can stretch and say “constant values” (assignments) are “like functions with no inputs,” but that’s not the mathematical definition of a function, and it’s not what FP is about.
I don’t think anyone, include the author, is arguing that supercollider meets that definition, but if you want to go from a technical definition then I don’t think supercollider is object oriented either as there are primitive classes (e.g. symbol) that don’t really behaviour like classes - i.e., you cant inherit from it meaning you can’t substitute something in its place. Ran into this problem when trying to create a symbol that followed some specific format for use in an IdentityDictionary.
Regarding assignment Vs function with no inputs, I think these might be isomorphic, and therefore, just a matter of syntax?
I think you missed the message I was replying to. I’m not saying that “supercollider needs to meet the definition”. The conversation was something else.
What I was trying to get at is that the first thing in programming is the idea, and that the idea is more important than the language. If you have an idea, you can consider ways to implement it. If that idea is lambda calculus, then the fact that SC is shot through with side effects doesn’t necessarily make it impossible to implement. It would be exceedingly difficult because SC doesn’t do anything to lead users in the direction of true functional programming – but you could rigorously write functions and methods that implement the idea, and which avoid areas in SC that are un-functional. This is – fully agreed! – impractical, but it is not impossible.
In that sense, yes, functional programming is a style in the sense that it is a set of practices that implement a specific idea of functions. You don’t need Haskell to write functional code (though it would be a smoother experience than trying to do it in SC, for sure).
Comrade, yes, I was wondering about the meaning given to the classification. Then I asked whether a method would be a “function without arguments,” since it would be a strange thing. And then, I suggested that the absence of side effects is not the only feature of FP, although an important one since the beginning. You can find that in ISWIM, created in the 60s.
Yes, there is no dichotomy here; there is a vast diversity of implementations. There is no need to go that way about it.
Fair enough, James. And probably lack of side effects would not be the most annoying thing. Passing functions as arguments and results would require some tricks too.
FWIW, I do realize that SC’s core isn’t anywhere close to lambda-calculus functional, and that it would be difficult to make even a small library that does lambda calculus for real. And performance would likely be quite bad, since creating and discarding e.g. arrays for every micro-operation would result in a massive garbage-collection load.
I had just thought that it was an interesting point to abstract out the idea of functional programming, separate from functional languages. I didn’t mean to trivialize FP at all.
