Hacker News Reader

Comment by ParetoOptimal | Hacker News Reader

> monadic complexity

In production Haskell I've seen it's typical you only need to understand how to use the common Maybe, Either, and IO monads. Maybe... sometimes... you need to create your own.

I actually think it's a bit of an anti-pattern, but this anti-pattern leads to a reality where the monadic complexity you alledge does not exist.

View on HN

In production Haskell you need to combine monads using e.g. monad transformers and this is significantly more complicated than just understanding how bind works. It also requires a lot of boilerplate code and any errors there are not obvious to track down.

Writing your own monad transformers is more complicated than understanding bind. Using standard ones isn't: swap out `State s a` for `MonadState s m => m a` (or whatever the relevant effects are) and put `lift` where the compiler tells you to, and you're 90% of the way there.

The other 10% is stacking the appropriate sequence of `FooBarT (BarBazT ... )` at the entry point to your program, which is admittedly pretty tedious.

> In production Haskell you need to combine monads using e.g. monad transformers

In some workplaces, yes. However it's pretty tenable to use https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_c... with no or few additional monads.

Alternatively, you can have just a few people that understand how to compose Monads and many others writing code within them.

I'm not sure if I think it's a best practice by any means, but it's a pattern I've seen that avoids having to include monad transformers in onboarding.

Also a much simpler alternative in my opinion to monad transformers is effectful:

https://github.com/haskell-effectful/effectful

Here's a talk on it:

https://www.youtube.com/watch?v=BUoYKBLOOrE

Reply on news.ycombinator.com