4 ms·

Great article, feeds all my prejudices. For example, I'm tempted to link to it in http://akkartik.name/post/modularity http://akkartik.name/post/modularity at t

Great article, feeds all my prejudices. For example, I'm tempted to link to it in http://akkartik.name/post/modularity http://akkartik.name/post/modularity at the point where I say that "There seems the very definite possibility that the sorts of programs we humans need to help with our lives on this planet intrinsically require state."

mbrock 11y ago
That's why Haskell programmers, for example, try to represent state in clear ways. The basic mathematical model of functions and values turns out to be able to represent state in several ways: the "monadic" way of composing state transforming functions; the "functional-reactive programming" way of modelling signals and events (which offers interesting solutions to the OP's game problems); various "interpreter" patterns; and so on. I point this out just because there's a widespread misunderstanding that pure functional programming is somehow opposed to modelling state. It's definitely not. It just involves building state models on the coherent basis of functions and values. Put simply, in Haskell, when your problem requires state, you can just use the "State" type, just like when you require I/O, you use the "IO" type.
- idanoeman 11y ago
  Absolutely. In "The Awkward Squad," SPJ says "Haskell is the finest imperative programming language in the world," not entirely tongue-in-cheek. :)
dkersten 11y ago
Immutable state, functional programming, etc, is not about eliminating state, its about isolating it and carefully managing it. In a standard-imperative-mutable world, you can never be completely sure that state isn't being modified behind your back, you can never be completely sure that concurrent access is safe, you can never be completely sure how far reaching state changes you make are. The idea, IMHO, isn't to remove state. All programs need state. All interesting programs need state that changes over time. The "big idea" is that these changes are isolated and managed carefully so that nobody can pull the rug out from under you and change something behind your back or in a way that makes concurrent access unsafe. Immutable data means that the data you are reading will never change. If you read it again in ten minutes, it will still give you the same value. No other module or thread can change it. Concurrent access is safe too and all reads give the same consistent view. But even immutable data needs to be updated, so there will always be some mutable state (for example, in Clojure, you might have one or more atoms, which are mutable cells into which you can put immutable data. The data doesn't mutate -- it gets replaced[0]. Only the cell is mutated, but in a carefully managed way. There are other mutable state management primitives too). The programmer cannot accidentally mess up the state, they have to intentionally do it. So to reiterate: its not about eliminating all mutable state, its about isolating and carefully managing it. [0] and anyone still holding a reference to the data (not the atom) will continue to see the same data as before, unchanged. That is, if I take the value from the atom, somebody else updating the atom will not change the value I took out of it. This of course introduces things like the dual-writes problem, but Clojure gives me other tools (like refs with STM) to tackle these: ie atoms aren't the right tool for all use cases, just one example I chose.

mbrock 11y ago

That's why Haskell programmers, for example, try to represent state in clear ways. The basic mathematical model of functions and values turns out to be able to represent state in several ways: the "monadic" way of composing state transforming functions; the "functional-reactive programming" way of modelling signals and events (which offers interesting solutions to the OP's game problems); various "interpreter" patterns; and so on. I point this out just because there's a widespread misunderstanding that pure functional programming is somehow opposed to modelling state. It's definitely not. It just involves building state models on the coherent basis of functions and values. Put simply, in Haskell, when your problem requires state, you can just use the "State" type, just like when you require I/O, you use the "IO" type.

idanoeman 11y ago
Absolutely. In "The Awkward Squad," SPJ says "Haskell is the finest imperative programming language in the world," not entirely tongue-in-cheek. :)

dkersten 11y ago

Immutable state, functional programming, etc, is not about eliminating state, its about isolating it and carefully managing it. In a standard-imperative-mutable world, you can never be completely sure that state isn't being modified behind your back, you can never be completely sure that concurrent access is safe, you can never be completely sure how far reaching state changes you make are. The idea, IMHO, isn't to remove state. All programs need state. All interesting programs need state that changes over time. The "big idea" is that these changes are isolated and managed carefully so that nobody can pull the rug out from under you and change something behind your back or in a way that makes concurrent access unsafe. Immutable data means that the data you are reading will never change. If you read it again in ten minutes, it will still give you the same value. No other module or thread can change it. Concurrent access is safe too and all reads give the same consistent view. But even immutable data needs to be updated, so there will always be some mutable state (for example, in Clojure, you might have one or more atoms, which are mutable cells into which you can put immutable data. The data doesn't mutate -- it gets replaced[0]. Only the cell is mutated, but in a carefully managed way. There are other mutable state management primitives too). The programmer cannot accidentally mess up the state, they have to intentionally do it. So to reiterate: its not about eliminating all mutable state, its about isolating and carefully managing it. [0] and anyone still holding a reference to the data (not the atom) will continue to see the same data as before, unchanged. That is, if I take the value from the atom, somebody else updating the atom will not change the value I took out of it. This of course introduces things like the dual-writes problem, but Clojure gives me other tools (like refs with STM) to tackle these: ie atoms aren't the right tool for all use cases, just one example I chose.