3 ms·

It's impossible to eliminate state, but the goal of functional programming is to have as little as possible. The original article does a great job of explaining

It's impossible to eliminate state, but the goal of functional programming is to have as little as possible. The original article does a great job of explaining how to do it and why that's an advantage in this case.

FpUser 4y ago
>"but the goal of functional programming is to have as little as possible." The goal is to produce optimal software not to serve particular paradigm.
- dtagames 4y ago
  Indeed. If the goals of functional programming help out in a particular instance and that style works for you, then use it.
- mrguyorama 4y ago
  Everything I have seen about "pure functional" programming has cared more about ideology than practicality.
  - dtagames 4y ago
    I had the opportunity to meet John Backus, the inventor of functional programming, when I worked at IBM. I definitely didn't "get it" the first time. Indeed, not until many years later. I wrote this article, Functional Programming in TS[0] which has a lot of good background info and explanations. At least I think so, lol! And it's been pretty popular. See what you think: [0] https://medium.com/gitconnected/functional-programming-in-typescript-18ac096bb551 https://medium.com/gitconnected/functional-programming-in-ty...
    - FpUser 4y ago
      Every concept is good when applied in the right place for the right cause. But programmers often tend to idolize particular tech to the degree that anything else is anathema.
klibertp 4y ago
To add to the sibling commenter - in my experience FP is not about having as little state as possible. It's about explicitly representing and tracking all state. OOP hides all state in private properties, FP displays the state as function arguments. In the end, you want a healthy mixture of both approaches. Sometimes state is better off hidden, and then in FP you need closures - might as well use an object then, instead of emulating it by creating a closure that "responds" to "messages" by manually dispatching arguments in a giant switch. I think OCaml, Scala, and Clojure got it right, on a language level, but then the problems float up into design - ie. where to use a mutable record and where to use a functional stream, etc. I don't think I saw a compelling set of guidelines how to mix the approaches in the most effective way.

FpUser 4y ago

>"but the goal of functional programming is to have as little as possible." The goal is to produce optimal software not to serve particular paradigm.

dtagames 4y ago
Indeed. If the goals of functional programming help out in a particular instance and that style works for you, then use it.
mrguyorama 4y ago
Everything I have seen about "pure functional" programming has cared more about ideology than practicality.
- dtagames 4y ago
  I had the opportunity to meet John Backus, the inventor of functional programming, when I worked at IBM. I definitely didn't "get it" the first time. Indeed, not until many years later. I wrote this article, Functional Programming in TS[0] which has a lot of good background info and explanations. At least I think so, lol! And it's been pretty popular. See what you think: [0] https://medium.com/gitconnected/functional-programming-in-typescript-18ac096bb551 https://medium.com/gitconnected/functional-programming-in-ty...
  - FpUser 4y ago
    Every concept is good when applied in the right place for the right cause. But programmers often tend to idolize particular tech to the degree that anything else is anathema.

klibertp 4y ago

To add to the sibling commenter - in my experience FP is not about having as little state as possible. It's about explicitly representing and tracking all state. OOP hides all state in private properties, FP displays the state as function arguments. In the end, you want a healthy mixture of both approaches. Sometimes state is better off hidden, and then in FP you need closures - might as well use an object then, instead of emulating it by creating a closure that "responds" to "messages" by manually dispatching arguments in a giant switch. I think OCaml, Scala, and Clojure got it right, on a language level, but then the problems float up into design - ie. where to use a mutable record and where to use a functional stream, etc. I don't think I saw a compelling set of guidelines how to mix the approaches in the most effective way.