4 ms·

But the point is the language doesn't need monads. You could express the same solution to the problem more verbosely without monads if the language couldn't exp

But the point is the language doesn't need monads. You could express the same solution to the problem more verbosely without monads if the language couldn't express monads. Consequently, monads are beside the point. Haskell needs to constrain the order of evaluation when it's dealing with the real world. There's a solution to that problem (require and yield `World`). Then we choose to use `IO` (i.e. a monad) to implement that solution. But the abstraction that is a monad is independently justified and worthwhile in languages like Typescript (I wish!) and ML which don't have the same IO issue. As long as we teach monads as if they have anything to do with IO we're confusing people. IO uses monads because it's convenient and apt. But monads don't control order of evaluation. They've got nothing to do with order of evaluation.

xfer 8y ago
> Then we choose to use `IO` (i.e. a monad) to implement that solution. Yes, we are in agreement, however i am arguing that haskell had to use monads here otherwise it would be very difficult to use. > As long as we teach monads as if they have anything to do with IO we're confusing people. Sure, but the introduction of monads in haskell came out of a real necessity is my point. Category theory is powerful tool for abstraction and useful in any language. > But monads don't control order of evaluation. They've got nothing to do with order of evaluation. Right, but they can hide the trick and make it all seem transparent, which imho is very important point to keep in mind.
thesz 8y ago
Haskell does not constrain the order of evaluation when dealing with real world. It constrains order of effects. The code "putStrLn this >> putStrLn that" is allowed to evaluate this and that in any order, basically. "that" may depend on "this" and vice versa. The very expressions "putStrLn a" is also not an action, but expression, being evaluated into actions. And the constrainment of effects is what makes Haskell special.

xfer 8y ago

> Then we choose to use `IO` (i.e. a monad) to implement that solution. Yes, we are in agreement, however i am arguing that haskell had to use monads here otherwise it would be very difficult to use. > As long as we teach monads as if they have anything to do with IO we're confusing people. Sure, but the introduction of monads in haskell came out of a real necessity is my point. Category theory is powerful tool for abstraction and useful in any language. > But monads don't control order of evaluation. They've got nothing to do with order of evaluation. Right, but they can hide the trick and make it all seem transparent, which imho is very important point to keep in mind.

thesz 8y ago

Haskell does not constrain the order of evaluation when dealing with real world. It constrains order of effects. The code "putStrLn this >> putStrLn that" is allowed to evaluate this and that in any order, basically. "that" may depend on "this" and vice versa. The very expressions "putStrLn a" is also not an action, but expression, being evaluated into actions. And the constrainment of effects is what makes Haskell special.