3 ms·

The state is there, of course. The goal here is to minimize the amount of state the code has access to at any particular time. Functional purity is not the goa

The state is there, of course. The goal here is to minimize the amount of state the code has access to at any particular time. Functional purity is not the goal, it's just one way to reduce state.

DrScientist 7y ago
So you still have state, but you can't get at it because it's been moved from the heap to the call stack? I'm not sure that makes programs: 1. Easily evolve-able. 2. Easy to understand. Well managed accessible state can be greatly simplifying. In my view the goal should be simple understandable code, not a meta-goal like removing all accessible state.
- ajconway 7y ago
  I don't know, actually. Should the state other that what the task (or sub-task) can observe matter for it to function? Where would be the boundary, as there are lots of things happening simultaneously in a computer, and the global state is huge.
- bradstewart 7y ago
  > Well managed accessible state can be greatly simplifying. Absolutely--and functional programming is one way to achieve that. From the perspective a given function, all "state" is captured in its inputs and outputs. You know exactly what existing state can be used by the function (inputs) and exactly what state can be generated by the function (outputs) simply from looking at the signature.
  - DrScientist 7y ago
    I'm talking about the difficultly of reasoning about high level application state when it isn't explicit. To take a low level example - sorting a list efficiently is easy with imperative programming and mutable state ( Note you can still encapsulate that state within a object - it doesn't need to be global ). On the other hand took about 20 years before somebody worked how to do it reasonably with a functional approach. Being obsessive about a pure functional approach and/or having a holy war against heap managed state is a mistake in my view. Functional approach is a tool in the toolbox, not a golden hammer.
    - bradstewart 7y ago
      Totally agreed. Being obsessive about (almost) anything in software is a recipe for pain.

The state is there, of course. The goal here is to minimize the amount of state the code has access to at any particular time. Functional purity is not the goal, it's just one way to reduce state.

DrScientist 7y ago

So you still have state, but you can't get at it because it's been moved from the heap to the call stack? I'm not sure that makes programs: 1. Easily evolve-able. 2. Easy to understand. Well managed accessible state can be greatly simplifying. In my view the goal should be simple understandable code, not a meta-goal like removing all accessible state.

ajconway 7y ago
I don't know, actually. Should the state other that what the task (or sub-task) can observe matter for it to function? Where would be the boundary, as there are lots of things happening simultaneously in a computer, and the global state is huge.
bradstewart 7y ago
> Well managed accessible state can be greatly simplifying. Absolutely--and functional programming is one way to achieve that. From the perspective a given function, all "state" is captured in its inputs and outputs. You know exactly what existing state can be used by the function (inputs) and exactly what state can be generated by the function (outputs) simply from looking at the signature.
- DrScientist 7y ago
  I'm talking about the difficultly of reasoning about high level application state when it isn't explicit. To take a low level example - sorting a list efficiently is easy with imperative programming and mutable state ( Note you can still encapsulate that state within a object - it doesn't need to be global ). On the other hand took about 20 years before somebody worked how to do it reasonably with a functional approach. Being obsessive about a pure functional approach and/or having a holy war against heap managed state is a mistake in my view. Functional approach is a tool in the toolbox, not a golden hammer.
  - bradstewart 7y ago
    Totally agreed. Being obsessive about (almost) anything in software is a recipe for pain.