Do you write imperative programs that execute statements — out of order? Ordering is precisely the point of monads, since they are monoids as well.
And sum types are most definitely not enums, though Rust’s enums do use a bit strange terminology here.
> Do you write imperative programs that execute statements — out of order? Ordering is precisely the point of monads, since they are monoids as well.
Sure do. After all, your superscalar CPU executes things out of order, and C is a pure functional language in the memory monad.
http://conal.net/blog/posts/the-c-language-is-purely-functio...
> And sum types are most definitely not enums, though Rust’s enums do use a bit strange terminology here.
Swift's enums too. But sure, in C it's an enum with a union at the end.
Well, being pedantic, sure almost every modern CPU uses OOE. But they must do so with the huge caveat that from the outside it should be equivalent to executing it in serial (notwithstanding CPU vulnerabilities). But this is an implementation detail only, we could just as well use an older CPU design.
I don't think Haskell composes that well; monads don't combine well (not that I could do better) since you can only stick them together in an ordered way, the lazy evaluation makes it complicated to see how your program will run by reading the code, and so on.
Btw, "sum types" means enums; it's not actually a super-complicated Haskell only feature.