4 ms·

I think these sorts of examples dodge the real issue. Of course you can show a (perhaps needlessly) verbose procedural example of an algorithm that lends itself

I think these sorts of examples dodge the real issue. Of course you can show a (perhaps needlessly) verbose procedural example of an algorithm that lends itself perfectly to FP and then demonstrate how FP is far more concise. But the real issue, in my view, is what happens when the algorithm is not ideally suited to FP, otherwise we're back to the cute inheritance hierarchies in OOP textbooks. Say we're dealing with something like the UK share matching rules [1], where you can't simply process your items in sequential order (because the cost of shares sold on a particular day may depend the cost of shares purchased on or after that day). The open question in my mind is whether pure functional languages scale well to problems of real life complexity, ugliness and the occasionally crucial optimization requirement. Does FP fall apart completely in those circumstances or does it just degrade to the point where procedural code was all along? I don't have an answer to that, but it may depend on how dogmatically the purity constraint is enforced. [1] https://www.accaglobal.com/uk/en/technical-activities/technical-resources-search/2014/december/share-matching-rules.html https://www.accaglobal.com/uk/en/technical-activities/techni...

DubiousPusher 7y ago
Agreed. My first thought was that you can do the exact same thing as the Haskell code in C++ using <algorithm> from the STL. The biggest advantage I find to functional languages is they force you to write code that's more testable and modular. I now actually write almost every OOP class to have all functionality in private static methods with the public interface methods mostly only doing the work of gathering the args for the private static methods.
ignoramous 7y ago
> The open question in my mind is whether pure functional languages scale well to problems of real life complexity. I came across this website [0] on news.yc way back when: It has a nice one-to-one mapping of GoF design patterns in C++/Java to Clojure. > The open question in my mind is whether pure functional languages scale well to problems of real life complexity OCaml [1] really shines in this aspect having used it in a project involving static code analysis. Facebook's ReasonML is based on it. The rust-lang compiler was once written in OCaml. And then there's amirmc's unikernel.org / mirage.io, as well. [0] https://mishadoff.com/blog/clojure-design-patterns/ https://mishadoff.com/blog/clojure-design-patterns/ [1] https://ocaml.org/learn https://ocaml.org/learn
isodude 7y ago
A simple thing like a DNS resolve is much simpler in non FP. FP shines when it's more complex, but not when it's simple. I find Go-lang a reasonable crossover where you could do a lot of FP in it where it is needed and keep it simple and boring in the rest. It's like me as an engineer: Don't use me for simple tasks because I will make them really complex.
- apta 7y ago
  > I find Go-lang a reasonable crossover where you could do a lot of FP in it When people talk about FP, they usually include things like pattern matching and generics, none of which golang has. Not to mention it actively prohibits chaining functions that return errors because of the botched way it decided to handle errors as a product type instead of the correct way as sum type. golang is a very imperative language with very little going for it.
  - isodude 7y ago
    Agreed, it's still relatively possible to invent stuff that is missing though. It will grow :)
    - apta 7y ago
      Not without having a proper way to handle errors, and generics at the very least.
  - n4r9 7y ago
    tbh if you have the ability to easily treat functions as first class citizens in a language then it's fair enough to say you can code functionally in it. I think the attitude "X is inherently a functional language" is being replaced by the idea that there are clusters of language properties with labels like "functional" or "object-oriented" or "array-based" or whatever, and that a language may overlap with bits of various clusters to a greater or lesser degree.
    - itsbruce 7y ago
willtim 7y ago
Haskell is perfectly capable of expressing imperative algorithms and mutable state. Such algorithms are still expressed using pure functions, pure functions that return IO actions.
- lolinder 7y ago
  And x86 assembler is perfectly capable of expressing pure functions. Such algorithms are still expressed using subroutines, subroutines that save and restore all state to its start state. The question isn't whether a language can express an algorithm, Church and Turing already proved that. The question is whether the language can do so scalably. We want to see nontrivial examples of FP applied to messy, side-effect-laden domains in a way that rivals other representations for clarity and maintainability.
  - willtim 7y ago
    Depends on what you mean by "scalable". Given that Haskell can track the use of effects and mutable state in its type system, might suggest that it allows such techniques to scale beyond a language that does not. Haskell also has syntactic and compiler support for imperative code, no encoding is necessary, so I don't think your analogy of writing FP in assembly is fair. Writing imperative code in Haskell is much the same as in Java.
    - lolinder 7y ago
      I'm not saying that Haskell is as bad at imperative as assembly is at functional, just that being able to accomplish all tasks in a single-paradigm language does not constitute proof that the language is suitable for all tasks. I love FP concepts, and I've enjoyed my experiments with Haskell. What I object to is that FP advocates don't push FP as a valuable addition to a larger toolbox, they push it as a single paradigm to rule them all. For daily work, I prefer a multi-paradigm language that allows me to choose a programming model that matches the domain well. (FWIW, I have the same problem with OOP advocates who try to squeeze everything into a class. Some things are better modeled as pure functions.)

DubiousPusher 7y ago

Agreed. My first thought was that you can do the exact same thing as the Haskell code in C++ using <algorithm> from the STL. The biggest advantage I find to functional languages is they force you to write code that's more testable and modular. I now actually write almost every OOP class to have all functionality in private static methods with the public interface methods mostly only doing the work of gathering the args for the private static methods.

ignoramous 7y ago

> The open question in my mind is whether pure functional languages scale well to problems of real life complexity. I came across this website [0] on news.yc way back when: It has a nice one-to-one mapping of GoF design patterns in C++/Java to Clojure. > The open question in my mind is whether pure functional languages scale well to problems of real life complexity OCaml [1] really shines in this aspect having used it in a project involving static code analysis. Facebook's ReasonML is based on it. The rust-lang compiler was once written in OCaml. And then there's amirmc's unikernel.org / mirage.io, as well. [0] https://mishadoff.com/blog/clojure-design-patterns/ https://mishadoff.com/blog/clojure-design-patterns/ [1] https://ocaml.org/learn https://ocaml.org/learn

isodude 7y ago

A simple thing like a DNS resolve is much simpler in non FP. FP shines when it's more complex, but not when it's simple. I find Go-lang a reasonable crossover where you could do a lot of FP in it where it is needed and keep it simple and boring in the rest. It's like me as an engineer: Don't use me for simple tasks because I will make them really complex.

apta 7y ago
> I find Go-lang a reasonable crossover where you could do a lot of FP in it When people talk about FP, they usually include things like pattern matching and generics, none of which golang has. Not to mention it actively prohibits chaining functions that return errors because of the botched way it decided to handle errors as a product type instead of the correct way as sum type. golang is a very imperative language with very little going for it.
- isodude 7y ago
  Agreed, it's still relatively possible to invent stuff that is missing though. It will grow :)
  - apta 7y ago
    Not without having a proper way to handle errors, and generics at the very least.
- n4r9 7y ago
  tbh if you have the ability to easily treat functions as first class citizens in a language then it's fair enough to say you can code functionally in it. I think the attitude "X is inherently a functional language" is being replaced by the idea that there are clusters of language properties with labels like "functional" or "object-oriented" or "array-based" or whatever, and that a language may overlap with bits of various clusters to a greater or lesser degree.
  - itsbruce 7y ago

willtim 7y ago

Haskell is perfectly capable of expressing imperative algorithms and mutable state. Such algorithms are still expressed using pure functions, pure functions that return IO actions.

lolinder 7y ago
And x86 assembler is perfectly capable of expressing pure functions. Such algorithms are still expressed using subroutines, subroutines that save and restore all state to its start state. The question isn't whether a language can express an algorithm, Church and Turing already proved that. The question is whether the language can do so scalably. We want to see nontrivial examples of FP applied to messy, side-effect-laden domains in a way that rivals other representations for clarity and maintainability.
- willtim 7y ago
  Depends on what you mean by "scalable". Given that Haskell can track the use of effects and mutable state in its type system, might suggest that it allows such techniques to scale beyond a language that does not. Haskell also has syntactic and compiler support for imperative code, no encoding is necessary, so I don't think your analogy of writing FP in assembly is fair. Writing imperative code in Haskell is much the same as in Java.
  - lolinder 7y ago
    I'm not saying that Haskell is as bad at imperative as assembly is at functional, just that being able to accomplish all tasks in a single-paradigm language does not constitute proof that the language is suitable for all tasks. I love FP concepts, and I've enjoyed my experiments with Haskell. What I object to is that FP advocates don't push FP as a valuable addition to a larger toolbox, they push it as a single paradigm to rule them all. For daily work, I prefer a multi-paradigm language that allows me to choose a programming model that matches the domain well. (FWIW, I have the same problem with OOP advocates who try to squeeze everything into a class. Some things are better modeled as pure functions.)