Re:Kotlin: A Language with a Bright Future
by lmm on Tuesday November 21, 2017 @04:05AM
(#15746705)
> 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.
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.