
Which monads Haskell developers use: An exploratory study - paulcarey
https://www.sciencedirect.com/science/article/pii/S0167642320301313
======
siraben
Haskeller here, some observations:

\- Not surprised that the state monad is the most commonly used one, it
essentially acts as an escape hatch to write more imperative-looking code

\- List monad least used, probably due to the fact that Haskell has list
comprehensions

\- Continuation monad is second least used, much like how many programmers
find Scheme's call/cc unintuitive, continuations can be complex conceptually
and have specific use cases that don't really appear in industry

\- The Error monad in mtl has been deprecated in favor of Except, looks like
there's still many packages left to update

Overall I'd say that mtl has penetrated quite well into the Haskell community,
any intermediate Haskeller likely knows it. However, I hope that in the future
more people end up using effect libraries such as fused-effects and polysemy
(based on the work on extensible effects[0]) which have compositional and
performance advantages.

Also, one common complaint from the effects community is how the IO monad is a
"sin bin" (as SPJ describes it) of effects. One ought to be able to express
more nuanced side effects such as network/disk access or console I/O.

 _When designing a program we should start thinking what effect we want to
achieve rather than which monad transformer to use. Instead of jumping
straight to StateT and so on, we ought to identify what transformation on the
world and its resources we wish to effect._

[0]
[http://okmij.org/ftp/Haskell/extensible/](http://okmij.org/ftp/Haskell/extensible/)

~~~
bad_user
> _One ought to be able to express more nuanced side effects such as network
> /disk access or console I/O._

That’s one way of solving the issue, but is IMO overkill. It doesn’t tell you
much about what side effects can be executed out of order, in parallel, etc.

It’s also yet another encapsulation leak, although I know Haskell devs have
this mentality that the signature should describe the implementation perfectly
(principle of least power), with which I very much disagree with.

Another way is to not describe IO-like values at all.

In many cases you can describe a data structure that can later be materialized
into an IO by an interpreter (e.g Free Applicative/Monad would be one way of
doing it).

~~~
asplake
> ...with which I very much disagree with

Say some more about that?

------
lmm
A big advantage of the monad abstraction is that you can define custom monads
to suit your business cases, but then reuse a lot of existing functionality
with those monads. So looking at which "standard" monads are most popular only
tells half the story.

~~~
prionassembly
This is probably true of every mathematical abstraction in wide usage.

A big advantage of the probability abstraction (as a "partial knowledge"
concept supported by Dutch Book/sure bet arguments) is that you can define
probability distributions to suit your business cases but then reuse a lot of
existing algorithms and even theorems (cutting down on computation).

~~~
siraben
> This is probably true of every mathematical abstraction in wide usage.

After learning the categorical definition of monads and how they arise in
math, I've noticed that programmers tend to have a very operational view of
monads, when they are more general than the examples in functional
programming.

A good example that came up in a propositional logic class was[0]

[0]
[https://en.wikipedia.org/wiki/Closure_operator](https://en.wikipedia.org/wiki/Closure_operator)

------
jakuboboza
I used most commonly IO and State monads.

but I didnt write any Haskell code for like 4 years now. So stuff could
change. Maybe GHC got fixed ;)

~~~
siraben
This study is about the usage of monads from the monad transformer library
(mtl) across Hackage.

