3 ms·

Frankly the two aren't equivalent in behavior. So of course the python version is simpler, it does less. The Haskell code equivalent to your python version is

Frankly the two aren't equivalent in behavior. So of course the python version is simpler, it does less. The Haskell code equivalent to your python version is almost as trivial. repl :: Int -> IO() repl state = do val <- readLn print ("Total: " ++ (show (val + state))) repl (val + state) main = repl 0

Chris_Newton 13y ago
So of course the python version is simpler, it does less. What does the Haskell version do that the Python doesn’t? In terms of externally observable behaviour they both prompt for inputs and then add them up. In terms of design they’re both infinite loops that maintain one item of state. I understand that the example was written to show the State monad, and obviously the same externally observable behaviour could be achieved in other ways in this simple case. My point is that in imperative languages you get that State behaviour for free, and unlike the simplified alternatives to the Haskell that rely on recursion instead, such as the one you posted, the imperative state-for-free model scales up when you start to get lots of state and mutation going on. It doesn’t start to suffer in performance metrics like speed or memory usage, nor does it start to have unpredictable performance characteristics in complex systems. As I’ve stated elsewhere in this thread, this argument is not meant to belittle Haskell or dismiss the clear advantages its model offers. I’m arguing that there is a price to making those things as explicit as Haskell does, and that price is probably too high for mainstream industrial acceptance, so if we’re going to reap the benefits of the sound foundations on an industry-wide scale, they need to be available more transparently.
- nightski 13y ago
  The imperative one scales alright, into an un-maintainable nightmare of bugs. The problem is that the imperative model places the entire burden in the programmers head (even when it may not even be code you wrote!) whereas the Haskell version makes everything explicit.
- stonemetal 13y ago
  As you say the Haskell version explicitly controls state, your python version doesn't. If the python version had access to the variables in question under locks with as much security as the Haskell version then they would be doing the same amount of work. Sure they don't do anything observably different but it is a daft example with no driving motivation for why someone would write code that way.

Chris_Newton 13y ago

So of course the python version is simpler, it does less. What does the Haskell version do that the Python doesn’t? In terms of externally observable behaviour they both prompt for inputs and then add them up. In terms of design they’re both infinite loops that maintain one item of state. I understand that the example was written to show the State monad, and obviously the same externally observable behaviour could be achieved in other ways in this simple case. My point is that in imperative languages you get that State behaviour for free, and unlike the simplified alternatives to the Haskell that rely on recursion instead, such as the one you posted, the imperative state-for-free model scales up when you start to get lots of state and mutation going on. It doesn’t start to suffer in performance metrics like speed or memory usage, nor does it start to have unpredictable performance characteristics in complex systems. As I’ve stated elsewhere in this thread, this argument is not meant to belittle Haskell or dismiss the clear advantages its model offers. I’m arguing that there is a price to making those things as explicit as Haskell does, and that price is probably too high for mainstream industrial acceptance, so if we’re going to reap the benefits of the sound foundations on an industry-wide scale, they need to be available more transparently.

nightski 13y ago
The imperative one scales alright, into an un-maintainable nightmare of bugs. The problem is that the imperative model places the entire burden in the programmers head (even when it may not even be code you wrote!) whereas the Haskell version makes everything explicit.
stonemetal 13y ago
As you say the Haskell version explicitly controls state, your python version doesn't. If the python version had access to the variables in question under locks with as much security as the Haskell version then they would be doing the same amount of work. Sure they don't do anything observably different but it is a daft example with no driving motivation for why someone would write code that way.