4 ms·

That doesn't really seem like a good summary of functional programming. It has state all over the place. But it's true that functional programming is about stat

That doesn't really seem like a good summary of functional programming. It has state all over the place. But it's true that functional programming is about state management. I'd argue that the functional approach to state management is to make state explicit and visible.

epolanski 4y ago
FP is about evaluating expressions and it doesn't have state all over the place. I would also add that statefulness is incredibly hard and complex to get right in complex applications and pure fp languages like haskell lack enough emphasis on runtimes to handle this gracefully.
- frutiger 4y ago
  > FP is about evaluating expressions and it doesn't have state all over the place. All the state is in the function stack and the instruction pointer.
  - EugeneOZ 4y ago
    While you can’t read the state, it's not a “state”, it's just a chaotic mess of data in memory.
- User23 4y ago
  > FP is about evaluating expressions and it doesn't have state all over the place. FP is all about side effects. Every time you declare something you're effecting a compile time side effect. And then there's monads, which are literally reinventing state with a worse API. I find it odd that no mainstream functional language has an explicit call stack monad and an explicit symbol table monad. Maybe because even the "purists" realize how asinine that would be. > I would also add that statefulness is incredibly hard and complex to get right in complex applications and pure fp languages like haskell lack enough emphasis on runtimes to handle this gracefully. Mutable state is a powerful tool. And it's true that if carpenters used table saws with the same level of discipline that programmers use compilers, there wouldn't be a carpenter left with any fingers. Nevertheless, powerful tools can be used in a responsible and disciplined way and if you do you can be highly confident no unexpected dismemberment, literal or metaphorical, will occur. Edit: to be more explicit, the mathematicians who invented Algol were well aware of all the theory for so-called functional programming and rejected it in favor of treating programs as transformations of a multidimensional space with good reason.
  - epolanski 4y ago
    > FP is all about side effects. Every programming language is about side effects. Computations that don't lead to side effects are useless. That being said fp splits a core functional part (pure, no side effects of any kind) and the interpreter part where the instructions are run. The way one should visualize pure functional programming is that functional programs don't _do_ anything. They are equivalent to producing a description of the operation. The actual execution happens when those descriptions (generally encoded in effects or data types such as IO/Task) are interpreted by an external runtime.
    - User23 4y ago
      > Every programming language is about side effects. > Computations that don't lead to side effects are useless. Right. > The way one should visualize pure functional programming is that functional programs don't _do_ anything. They are equivalent to producing a description of the operation. The actual execution happens when those descriptions (generally encoded in effects or data types such as IO/Task) are interpreted by an external runtime. This is the right way to understand imperative programming too. The program really doesn't do anything, it just describes a set of possible processes. Then the runtime converts the program into one of those processes (or maybe more than one). Each of those processes is a path through a program state space graph, but supposing your process is to have visual effects at various nodes in that graph the runtime will do externally visible things. It's really not any different. In the end FP is basically just a way to force programming in a SSA style, plus whatever silliness the designers go for to deal with the reality that mathematical functions can't really capture input and output in any sort of useful way. Interestingly, it appears to me that in pure math the vernacular text around the equations fulfills that role.
deleted 4y ago
[deleted]

epolanski 4y ago

FP is about evaluating expressions and it doesn't have state all over the place. I would also add that statefulness is incredibly hard and complex to get right in complex applications and pure fp languages like haskell lack enough emphasis on runtimes to handle this gracefully.

frutiger 4y ago
> FP is about evaluating expressions and it doesn't have state all over the place. All the state is in the function stack and the instruction pointer.
- EugeneOZ 4y ago
  While you can’t read the state, it's not a “state”, it's just a chaotic mess of data in memory.
User23 4y ago
> FP is about evaluating expressions and it doesn't have state all over the place. FP is all about side effects. Every time you declare something you're effecting a compile time side effect. And then there's monads, which are literally reinventing state with a worse API. I find it odd that no mainstream functional language has an explicit call stack monad and an explicit symbol table monad. Maybe because even the "purists" realize how asinine that would be. > I would also add that statefulness is incredibly hard and complex to get right in complex applications and pure fp languages like haskell lack enough emphasis on runtimes to handle this gracefully. Mutable state is a powerful tool. And it's true that if carpenters used table saws with the same level of discipline that programmers use compilers, there wouldn't be a carpenter left with any fingers. Nevertheless, powerful tools can be used in a responsible and disciplined way and if you do you can be highly confident no unexpected dismemberment, literal or metaphorical, will occur. Edit: to be more explicit, the mathematicians who invented Algol were well aware of all the theory for so-called functional programming and rejected it in favor of treating programs as transformations of a multidimensional space with good reason.
- epolanski 4y ago
  > FP is all about side effects. Every programming language is about side effects. Computations that don't lead to side effects are useless. That being said fp splits a core functional part (pure, no side effects of any kind) and the interpreter part where the instructions are run. The way one should visualize pure functional programming is that functional programs don't _do_ anything. They are equivalent to producing a description of the operation. The actual execution happens when those descriptions (generally encoded in effects or data types such as IO/Task) are interpreted by an external runtime.
  - User23 4y ago
    > Every programming language is about side effects. > Computations that don't lead to side effects are useless. Right. > The way one should visualize pure functional programming is that functional programs don't _do_ anything. They are equivalent to producing a description of the operation. The actual execution happens when those descriptions (generally encoded in effects or data types such as IO/Task) are interpreted by an external runtime. This is the right way to understand imperative programming too. The program really doesn't do anything, it just describes a set of possible processes. Then the runtime converts the program into one of those processes (or maybe more than one). Each of those processes is a path through a program state space graph, but supposing your process is to have visual effects at various nodes in that graph the runtime will do externally visible things. It's really not any different. In the end FP is basically just a way to force programming in a SSA style, plus whatever silliness the designers go for to deal with the reality that mathematical functions can't really capture input and output in any sort of useful way. Interestingly, it appears to me that in pure math the vernacular text around the equations fulfills that role.

deleted 4y ago

[deleted]