4 ms·

The most important feature of monads definitely isn't composition, because they don't compose well at all. Monad composition is the worst feature, by far, becau

The most important feature of monads definitely isn't composition, because they don't compose well at all. Monad composition is the worst feature, by far, because it doesn't exist. >Also, as someone in the Haskell industry, I think you're wrong about trends. The last 5 or so years have been an accelerating trend of Haskell adoption. Of course it is still dwarfed by most other languages, but the number of multi-million dollar contracts I've seen executed in Haskell has been multiplying. That's my point: that's the hype cycle, and it's now peaking as people realise what a lot of effort it is to actually use monads in reality with the awful complexity of monad transformer stacks and such.

kreetx 9y ago
Can you clarify what do you mean by they don't compose at all? It feels like you've had some tough experiences with monads (monad transformers), and I agree, they are hard to get into.
- lambdas 9y ago
  Sometimes two monads composed don't form another monad. Unlike Functors and Applicatives. Simple example, if you have a list containing functions ([Reader r a]) it forms an Applicative fine as they compose. However you can't satisfy the conditions needed to form a Monad.
  - danharaj 9y ago
    You can compose monads whenever you have a distributive law for them. Usually there's an obvious one. In your example there's a distributive law that uses the same parameter for every function, this allows you to compose the monads. When there's several possible distributive laws or none, that's important. It means that either the interactions between the two effects are subtle and need to be further specified or they are completely incompatible. Algebraic effects can only handle effects that trivially commute. So monad composition is a finer, thus more expressive operation.
    - alphaalpha101 9y ago
      This reminds me of the 'fine-grained permissions' vs. 'broad permissions' security models. The former is more expressive, more powerful, etc. It also is technical, complicated and confusing. The latter is less powerful and less expressive, but people actually use it, because it's simple and easy to understand. Expressing effects using monad transformer stacks might be more expressive and allow finer-grained distinctions, or whatever (please elaborate what you mean, I'm interested), but it's syntactically ugly (lift), it's confusing, and it's not clear that the expressiveness you get is practically useful. In contrast, algebraic effects might 'only handle effects that trivially commute' (again, going to need more detail on this), but they're easy to understand and easy to use. They're much more likely to be a practically usable effect system that real programmers can really use in the real world in a way that doesn't convolute code with details of how you compose effects unduly.

kreetx 9y ago

Can you clarify what do you mean by they don't compose at all? It feels like you've had some tough experiences with monads (monad transformers), and I agree, they are hard to get into.

lambdas 9y ago
Sometimes two monads composed don't form another monad. Unlike Functors and Applicatives. Simple example, if you have a list containing functions ([Reader r a]) it forms an Applicative fine as they compose. However you can't satisfy the conditions needed to form a Monad.
- danharaj 9y ago
  You can compose monads whenever you have a distributive law for them. Usually there's an obvious one. In your example there's a distributive law that uses the same parameter for every function, this allows you to compose the monads. When there's several possible distributive laws or none, that's important. It means that either the interactions between the two effects are subtle and need to be further specified or they are completely incompatible. Algebraic effects can only handle effects that trivially commute. So monad composition is a finer, thus more expressive operation.
  - alphaalpha101 9y ago
    This reminds me of the 'fine-grained permissions' vs. 'broad permissions' security models. The former is more expressive, more powerful, etc. It also is technical, complicated and confusing. The latter is less powerful and less expressive, but people actually use it, because it's simple and easy to understand. Expressing effects using monad transformer stacks might be more expressive and allow finer-grained distinctions, or whatever (please elaborate what you mean, I'm interested), but it's syntactically ugly (lift), it's confusing, and it's not clear that the expressiveness you get is practically useful. In contrast, algebraic effects might 'only handle effects that trivially commute' (again, going to need more detail on this), but they're easy to understand and easy to use. They're much more likely to be a practically usable effect system that real programmers can really use in the real world in a way that doesn't convolute code with details of how you compose effects unduly.