4 ms·

> How so? What's the generality that's missing here? Again, completely permissive doesn't necessarily mean more general. Monads – or rather, what Haskell and S

> How so? What's the generality that's missing here? Again, completely permissive doesn't necessarily mean more general. Monads – or rather, what Haskell and Scala use monads for, to distinguish that from the category theory concept – are primarily about "enriched" function composition (yes, I know that I'm simplifying here). That is useful, but also very limiting when the logic with which you want to glue pieces of code together does not fit that schema. A lot of the usefulness of monads also depends on the language supporting the syntactic sugar ("do" in Haskell or "for" in Scala) to make the resulting code readable. > Monads are a synecdoche because they happen to come up quite often, but they're really just one reusable construction among many, and certainly admit a couple of useful generalisations. I'd argue that monads are an artifact of pure functional programming (or attempts to approximate pure functional programming in impure languages). As soon as you have mutable local state and closures, virtually all use cases of monads for programming (not counting actual category theory applications) disappear. Note that I'm saying mutable local state. The arguments against mutable global state do not really apply to local state. Thus, for those other languages, most of the practical need for monads disappears and monads really become a more limited way of expressing higher-order program logic.

lmm 9y ago
> Monads – or rather, what Haskell and Scala use monads for, to distinguish that from the category theory concept – are primarily about "enriched" function composition (yes, I know that I'm simplifying here). That is useful, but also very limiting when the logic with which you want to glue pieces of code together does not fit that schema What kind of logic might that be? You keep saying there's a generalisation but you keep not showing what it actually is. > A lot of the usefulness of monads also depends on the language supporting the syntactic sugar ("do" in Haskell or "for" in Scala) to make the resulting code readable. Up to a point. I've done some work with (free) applicatives lately, which have no direct language support, but it turns out you can get a lot of the value anyway. > I'd argue that monads are an artifact of pure functional programming (or attempts to approximate pure functional programming in impure languages). As soon as you have mutable local state and closures, virtually all use cases of monads for programming (not counting actual category theory applications) disappear. I find them useful for any kind of cross-cutting concern - all the AOP examples. Audit logs, database transactions, validation, authorization, that kind of thing. To solve these things with something state-like that state has to be pseudo-global and has most of the problems of global state; to solve them with closures you need a way to compose closures at which point you're most of the way to monads.

lmm 9y ago

> Monads – or rather, what Haskell and Scala use monads for, to distinguish that from the category theory concept – are primarily about "enriched" function composition (yes, I know that I'm simplifying here). That is useful, but also very limiting when the logic with which you want to glue pieces of code together does not fit that schema What kind of logic might that be? You keep saying there's a generalisation but you keep not showing what it actually is. > A lot of the usefulness of monads also depends on the language supporting the syntactic sugar ("do" in Haskell or "for" in Scala) to make the resulting code readable. Up to a point. I've done some work with (free) applicatives lately, which have no direct language support, but it turns out you can get a lot of the value anyway. > I'd argue that monads are an artifact of pure functional programming (or attempts to approximate pure functional programming in impure languages). As soon as you have mutable local state and closures, virtually all use cases of monads for programming (not counting actual category theory applications) disappear. I find them useful for any kind of cross-cutting concern - all the AOP examples. Audit logs, database transactions, validation, authorization, that kind of thing. To solve these things with something state-like that state has to be pseudo-global and has most of the problems of global state; to solve them with closures you need a way to compose closures at which point you're most of the way to monads.