3 ms·

"Functional - Modifying state is hard to get correct; keep it at the boundaries and keep logic pure so that it is easier to verify the logic is correct." My ma

"Functional - Modifying state is hard to get correct; keep it at the boundaries and keep logic pure so that it is easier to verify the logic is correct." My main beef with functional programming is that you essentially put the state in the "instruction pointer" and its history of walking the call stack instead of bound to symbols. It does not fit my way of thought. I personally prefer more or less statemachines.

xwdv 4y ago
You don’t need history. Embrace one way data flow and your life will be simpler and more easy to reason about.
epgui 4y ago
I think what you're missing is that functional programming is about referential transparency. There should be no need for an instruction pointer in your mental model.
- deleted 4y ago
  [deleted]
- vc8f6vVV 4y ago
  Not really. Try to interact with DB in FP. Yes, there is a referential transparency ... when combining functions which call DB (e.g. using monads). As a result you get a composite function, which is the same every time you run that composition. Who cares really? When you execute that composite function though you will potentially get different results and your "referential transparency" goes out the window. Of course one can write a "pure" FP program without effects, but any side effect reduces referential transparency to combining functions, is it really easier to reason about computations this way? Nope, it is not. Basically how FP sells: def a 1 end def b 2 end def c a + b end You see? c = 3! Now try to apply this logic to (real world with effects): def a (conn: DBConn) => { .... some complex code ... } end def b (conn: DBConn) => { .. another complex code ... } end def c (conn: DBConn) => a(conn) + b(conn) end So c = ? Still transparent?
  - ARandomerDude 4y ago
    DB operations are not what is being described in the conversation about referential transparency. We’re talking about something that starts with things like reduce vs. a for loop with mutable variables to accumulate values. Once the language forces you to think in terms of stateful operations to perform even basic tasks, the reflexive tendency is to use mutable state to perform any task. At that point, nobody really knows what a functional does because you have to understand the entire system to know what the output of a function will be.
    - vc8f6vVV 4y ago
      But we do have loops in the real world, don't we? So in a true FP we are talking about recursion as an alternative to for loops. Can you easily reduce recursive function? If you can, I can as well "reduce" for loop. Otherwise we are talking about a paradigm without recursions and side effects.
      - ARandomerDude 4y ago
        https://clojuredocs.org/clojure.core/reduce https://clojuredocs.org/clojure.core/reduce
        vc8f6vVV 4y ago
        Recursion, what was the point of the link?
        epgui 4y ago
        Your problem is that you’re trying too hard to argue and your time would be better spent trying to understand.
  - vore 4y ago
    No, but this is why we have things like linear types or encapsulating side effects in a state monad to describe these kinds of strict sequencings. I personally think pure functional programming is still very unergonomic but referential transparency in the face of side effects is not an unsolved problem. Besides, it's good practice to limit how widespread side effects are in any program, anyway.
Twisol 4y ago
Is this another way of putting what you're saying? In functional programming, we think of computation as reducing an expression; a computation is complete when it can't be reduced anymore. In imperative programming, we think of computation as updating a store of data; a computation is complete when we run out of steps to perform. When you're partway through execution, the "rest of the program" in an imperative system is captured by the current state of the store (including the stack). In a functional program, the "rest of the program" is just the program expression itself, reduced as it has been up to this point. I tend to like the functional model, myself, but I can see the mental appeal of keeping the program text fixed, and isolating all changes to a separate store of data.
dustingetz 4y ago
modern FP (effect systems) says the opposite - having separating the pure from the impure, we can now bring them back together and orchestrate fine grained fabrics of effects at greater scale with deterministic lifecycle and strong real source cleanup guarantees; for example signals based reactive dom rendering

xwdv 4y ago

You don’t need history. Embrace one way data flow and your life will be simpler and more easy to reason about.

epgui 4y ago

I think what you're missing is that functional programming is about referential transparency. There should be no need for an instruction pointer in your mental model.

deleted 4y ago
[deleted]
vc8f6vVV 4y ago
Not really. Try to interact with DB in FP. Yes, there is a referential transparency ... when combining functions which call DB (e.g. using monads). As a result you get a composite function, which is the same every time you run that composition. Who cares really? When you execute that composite function though you will potentially get different results and your "referential transparency" goes out the window. Of course one can write a "pure" FP program without effects, but any side effect reduces referential transparency to combining functions, is it really easier to reason about computations this way? Nope, it is not. Basically how FP sells: def a 1 end def b 2 end def c a + b end You see? c = 3! Now try to apply this logic to (real world with effects): def a (conn: DBConn) => { .... some complex code ... } end def b (conn: DBConn) => { .. another complex code ... } end def c (conn: DBConn) => a(conn) + b(conn) end So c = ? Still transparent?
- ARandomerDude 4y ago
  DB operations are not what is being described in the conversation about referential transparency. We’re talking about something that starts with things like reduce vs. a for loop with mutable variables to accumulate values. Once the language forces you to think in terms of stateful operations to perform even basic tasks, the reflexive tendency is to use mutable state to perform any task. At that point, nobody really knows what a functional does because you have to understand the entire system to know what the output of a function will be.
  - vc8f6vVV 4y ago
    But we do have loops in the real world, don't we? So in a true FP we are talking about recursion as an alternative to for loops. Can you easily reduce recursive function? If you can, I can as well "reduce" for loop. Otherwise we are talking about a paradigm without recursions and side effects.
    - ARandomerDude 4y ago
      https://clojuredocs.org/clojure.core/reduce https://clojuredocs.org/clojure.core/reduce
      - vc8f6vVV 4y ago
        Recursion, what was the point of the link?
        epgui 4y ago
        Your problem is that you’re trying too hard to argue and your time would be better spent trying to understand.
- vore 4y ago
  No, but this is why we have things like linear types or encapsulating side effects in a state monad to describe these kinds of strict sequencings. I personally think pure functional programming is still very unergonomic but referential transparency in the face of side effects is not an unsolved problem. Besides, it's good practice to limit how widespread side effects are in any program, anyway.

Twisol 4y ago

Is this another way of putting what you're saying? In functional programming, we think of computation as reducing an expression; a computation is complete when it can't be reduced anymore. In imperative programming, we think of computation as updating a store of data; a computation is complete when we run out of steps to perform. When you're partway through execution, the "rest of the program" in an imperative system is captured by the current state of the store (including the stack). In a functional program, the "rest of the program" is just the program expression itself, reduced as it has been up to this point. I tend to like the functional model, myself, but I can see the mental appeal of keeping the program text fixed, and isolating all changes to a separate store of data.

dustingetz 4y ago

modern FP (effect systems) says the opposite - having separating the pure from the impure, we can now bring them back together and orchestrate fine grained fabrics of effects at greater scale with deterministic lifecycle and strong real source cleanup guarantees; for example signals based reactive dom rendering