3 ms·

This is a generic "no true Scotsman" argument. Not everybody shares the same definition of FP and while "My definition of FP is what Haskell gives me, and the a

This is a generic "no true Scotsman" argument. Not everybody shares the same definition of FP and while "My definition of FP is what Haskell gives me, and the author's definition is more akin to what Clojure and Elixir give them" is a correct statement, it's also not a very insightful point. You can't deny that there are lots of languages and techniques that people call "functional" where the key ingredient isn't "programs composed as an evaluation of a single expression" but something else (such as "immutable state").

ilovecaching 8y ago
Please see my explanatory reply where I described the key components of FP. I don't deny that there are lots of languages people call functional or multi-paradigm that are in fact not functional or are only borrowing some ingredients without providing enough to follow the paradigm. When we define a paradigm, we are defining the core abstraction of how programs are constructed. In FP, that would be composing functions, hence the name. We FPers borrow or share concepts with OOers. The State monad (our basic building block of holding state) is very much like OO method chaining for example. But those similarities do not make either equatable with the other.
Qwertystop 8y ago
Elixir's got |> for composition and & for currying (as well as for lambdas); I'm not sure that's the best language example for differences (given the specific things grandparent listed of things languages are missing).
- christophilus 8y ago
  Clojure's got `(->` and many other useful macros that are the equivalent of `|>` (well, more flexible, in fact), and it has support for currying, so I think it's probably relevant.
- skrebbel 8y ago
  |> isn't proper partial function application. It can only apply a single parameter and you can't store a piped-into function in a variable the way you can a partially applied function in eg Haskell. Eg the following won't work: splitname = name |> String.split splitname.(" ") Also, it's a stretch to call & currying. It's shorthand syntax for making an anonymous function. If & is currying, then the following JS code is also currying: const cube = a => Math.pow(a, 3) Elixir doesn't have currying or partial function application any more than JS or C# do. If your definition of "functional" requires these features then Elixir isn't functional (and that's fine).
bunderbunder 8y ago
OOP's got a similar problem: When the idea was originally dreamed up, message passing was an essential part of the definition. This wasn't an arbitrary thing, message passing was a precondition of the characteristics that people were trying to achieve in the first place. Nowadays, the definition's been deeply watered down, and there are vanishingly few languages that both call themselves object oriented and stick to the original idea. So maybe it's not worth fighting over the terminology anymore. But still, I can't help but feel like we've lost something in the process. FP didn't become the darling until more recently, and I think that it's just possible that people could hold the line and prevent the term from being watered down. And the original idea was very much one of programs that were composed of smaller parts, such that the whole thing was ultimately just the evaluation of a single expression. Note that this definition predates Haskell by a decade or so. It was trying to capture what the designers of APL were going for.
- ilovecaching 8y ago
  Yes, it's a game of chinese whispers, and the issue is usually people from another paradigm (OO) who aren't immersing themselves in FP enough to understand what it is and isn't. Then you have a few people who take bits and pieces and stick them in another language, and call it multi-paradigm. These communities normally have very few people who actually know enough about FP to teach it to the OOers. It's kind of a bubble problem. You need experienced FPers to teach the paradigm and dispel the rumors. All of this really boils down to what a paradigm is: it's not a set of features, it's a mindset and an approach to programming that a language facilitates.

ilovecaching 8y ago

Please see my explanatory reply where I described the key components of FP. I don't deny that there are lots of languages people call functional or multi-paradigm that are in fact not functional or are only borrowing some ingredients without providing enough to follow the paradigm. When we define a paradigm, we are defining the core abstraction of how programs are constructed. In FP, that would be composing functions, hence the name. We FPers borrow or share concepts with OOers. The State monad (our basic building block of holding state) is very much like OO method chaining for example. But those similarities do not make either equatable with the other.

Qwertystop 8y ago

Elixir's got |> for composition and & for currying (as well as for lambdas); I'm not sure that's the best language example for differences (given the specific things grandparent listed of things languages are missing).

christophilus 8y ago
Clojure's got `(->` and many other useful macros that are the equivalent of `|>` (well, more flexible, in fact), and it has support for currying, so I think it's probably relevant.
skrebbel 8y ago
|> isn't proper partial function application. It can only apply a single parameter and you can't store a piped-into function in a variable the way you can a partially applied function in eg Haskell. Eg the following won't work: splitname = name |> String.split splitname.(" ") Also, it's a stretch to call & currying. It's shorthand syntax for making an anonymous function. If & is currying, then the following JS code is also currying: const cube = a => Math.pow(a, 3) Elixir doesn't have currying or partial function application any more than JS or C# do. If your definition of "functional" requires these features then Elixir isn't functional (and that's fine).

bunderbunder 8y ago

OOP's got a similar problem: When the idea was originally dreamed up, message passing was an essential part of the definition. This wasn't an arbitrary thing, message passing was a precondition of the characteristics that people were trying to achieve in the first place. Nowadays, the definition's been deeply watered down, and there are vanishingly few languages that both call themselves object oriented and stick to the original idea. So maybe it's not worth fighting over the terminology anymore. But still, I can't help but feel like we've lost something in the process. FP didn't become the darling until more recently, and I think that it's just possible that people could hold the line and prevent the term from being watered down. And the original idea was very much one of programs that were composed of smaller parts, such that the whole thing was ultimately just the evaluation of a single expression. Note that this definition predates Haskell by a decade or so. It was trying to capture what the designers of APL were going for.

ilovecaching 8y ago
Yes, it's a game of chinese whispers, and the issue is usually people from another paradigm (OO) who aren't immersing themselves in FP enough to understand what it is and isn't. Then you have a few people who take bits and pieces and stick them in another language, and call it multi-paradigm. These communities normally have very few people who actually know enough about FP to teach it to the OOers. It's kind of a bubble problem. You need experienced FPers to teach the paradigm and dispel the rumors. All of this really boils down to what a paradigm is: it's not a set of features, it's a mindset and an approach to programming that a language facilitates.