4 ms·
Pure Functions is indeed a factor, but not the only one. Other irrelevant factors are pattern matching, tail call recursion, recursion instead of loops, etc. FP
by oaiey 4y ago
Pure Functions is indeed a factor, but not the only one. Other irrelevant factors are pattern matching, tail call recursion, recursion instead of loops, etc. FP is about treating data differently and dealing with side effects differently. Pure Functions are an implementation strategy of FP, not the core differentiator.
And that data/side effect difference, you can easily handle in Java, C# and other OO languages if you just overcome the culture of OO-only thinking. And despite I think the article is not perfect (who says, that a function cannot have a class/interface wrapper (aka strategy)), there is an element of truth in the spirit of the headline.
- grumpyprole 4y ago> Pure Functions are an implementation strategy of FP, not the core differentiator. "Functional Programming" is not a well-defined term. But I would argue that if you are not using pure functions then you have more of a hybrid imperative/functional language, which is fine, especially if you are careful with how you structure your effects. Modern FP languages use monads (Haskell) and/or algebraic effects (Eff) to enable pure functions to describe effects. The pure function is what enables mathematical reasoning and safe function composition.
- kaba0 4y agoWhat about the Lispian way of FP, e.g. Clojure? It is noting like the Haskellian one, yet they are also on the same spectrum.
- grumpyprole 4y agoClojure encourages pure functions and immutable data, so definitely a "functional first" language. But it's not a "purely functional" language.
- kaba0 4y agoI don’t think there is a boolean pureness flag, rather a spectrum. Haskell can also introduce arbitrary side effects in any code with some unsafe escape hatches, but sure, the common case doesn’t employ that, so it is a bit more pure than Clojure.