3 ms·

I tend to use the term "function-oriented" rather than "functional" since I think it fits the spirit of the phrase better. You're right that language features a

by lmkg 9y ago

I tend to use the term "function-oriented" rather than "functional" since I think it fits the spirit of the phrase better. You're right that language features alone won't distinguish enough, and that means that functional programming is more about culture and standard practices. Once you embrace that, it's a bit easier to wrangle out a definition. The definition I have in my head is something along the lines of "functions are the tool that the language prefers to address common software design concerns." So for example, Encapsulation is a big deal when designing software. Object-oriented languages will address this concern with their object system (via accessibility modifiers), while function-oriented languages tend to address this with functions, via lexical scoping and closures. OOP languages use their object system to achieve runtime-dynamic behavior through inheritance or composition or interfaces, while function-oriented languages will more often try to pass first-class functions as arguments. And so forth. It's not a 100% thing. Common Lips will solve some of its problems with macros or its module system, and ML will solve some of its problems with types. But you do find the languages (or communities) prefer functions over their object systems, while e.g. Python or Ruby prefer the reverse. Although, I do find myself wondering if Haskell should actually be considered a type-oriented language. Again, it's not just about the features of the type system, it's the fact that the type system is the main tool that it tries to use to solve every problem about designing software.

jholman 9y ago
I strongly agree. We see a lot of definitions of functional bandied about, often conflating functional with Haskell or with Scala. Those definitions seem to ignore the history of functional programming, including Lisp, as qsymmachus noted. So that's silly. And conversely, one sees a lot of definitions of OO that appear to mean "Java" or "C++". Again, nonsensical when one considers Self, or to a lesser degree Smalltalk. I do like your conception wherein a language is function to the degree to which it prefers functions as its favourite tool for solving problems, and/or OO to the degree to which it prefers objects as its favourite tool. Regarding encapsulation as your particular example, OO is clearly fairly obsessed with encapsulation, being almost the definition of an object: a bundle of encapsulated state with the externally-facing behaviour that that object affords. I think that many functional communities/practitioners see this as a much less urgent issue, often going so far as to make no active effort toward encapsulation at all (i.e. not everyone bothers with the lexical-scopes-and-closures solution). Thus we get ideas like "smart functions, dumb data", an idea which makes no sense in OO land.

by lmkg 9y ago

jholman 9y ago

I strongly agree. We see a lot of definitions of functional bandied about, often conflating functional with Haskell or with Scala. Those definitions seem to ignore the history of functional programming, including Lisp, as qsymmachus noted. So that's silly. And conversely, one sees a lot of definitions of OO that appear to mean "Java" or "C++". Again, nonsensical when one considers Self, or to a lesser degree Smalltalk. I do like your conception wherein a language is function to the degree to which it prefers functions as its favourite tool for solving problems, and/or OO to the degree to which it prefers objects as its favourite tool. Regarding encapsulation as your particular example, OO is clearly fairly obsessed with encapsulation, being almost the definition of an object: a bundle of encapsulated state with the externally-facing behaviour that that object affords. I think that many functional communities/practitioners see this as a much less urgent issue, often going so far as to make no active effort toward encapsulation at all (i.e. not everyone bothers with the lexical-scopes-and-closures solution). Thus we get ideas like "smart functions, dumb data", an idea which makes no sense in OO land.