> So the tension around types comes from the fact that if you want to program in a style that turns effects into explicit things that get passed around. > We n

> So the tension around types comes from the fact that if you want to program in a style that turns effects into explicit things that get passed around. > We now need some way of translating code with side effects into code that returns a value. One reasonable abstraction is to say that the "value" is not the work itself — once the work is done it's out of the bag, after all — but rather the "value" is the machine which can perform that work. It's also worth pointing out that this is precisely why Monads are the abstraction level of choice for a great deal of DSLs (there are some good applicative DSLs for parsing and applicative FRP things as well, but most DSLs have Monad transformers and such as the desired interface). And since this is the syntax and abstraction target for most DSLs, and DSLs are great, Monads often get brought up quite quickly in discussions of languages that use them (notably, Haskell).