List is a monad

Functor / Applicative context

• Several comments note that map comes from Functor, and every Monad is an Applicative, and every Applicative a Functor.
• Example: standard list vs ZipList show different Applicative (cross-product vs zip/dot-product) even though both support fmap. ZipList is Applicative but has no good Monad instance.

Mathematical precision and the title

• Multiple commenters object to “A list is a monad”: a list value is not a monad; the List type constructor can be given monad structure.
• There isn’t a single “list monad”: there are multiple lawful Monad instances for lists (e.g. standard vs zippy vs “exotic” list monads).
• One correction: an algebra for the List monad is (essentially) a monoid; “a list is an algebra for the List monad” is false.
• Some want the post retitled to something like “List has a Monad instance” to avoid misleading readers.

How to teach and understand monads

• Many praise the article’s “containers vs recipes” split but argue most monad tutorials over-emphasize “what is a monad in general” instead of teaching each common monad (Maybe, IO, State, List) separately.
• Several emphasize that the category-theory slogan (“monoid in the category of endofunctors”) is not necessary for practical programming and often intimidates learners.
• Others defend the math: category theory unifies “trivial” patterns; understanding monads categorically explains why generic monad-only code is so constrained and reliable.

Practical value of the Monad interface

• Pro-monad side:

  • Enables lots of reusable generic combinators (mapM, sequence, traverse, liftM2/liftA2, folds, traversals).
  • Powers syntax sugar (do notation, for-comprehensions, async/await-like patterns) that works for any monad, not just built-ins.
  • Supports effect-polymorphic code (e.g. MonadIO, testing code in Identity vs running it in IO).
  • Gives “chunking” of patterns: once you know the laws, you can reason about many different structures the same way.

• Skeptical side:

  • Some claim monads are mostly a workaround for Haskell’s insistence on referential transparency and not especially useful in mainstream languages.
  • Others see the abstraction as weak on its own: most real work depends on the particular monad, and transformers/composition are awkward.
  • A few call the entire concept “pointless” for everyday industry work, arguing they’ve never needed to name or understand monads explicitly.

Type systems and language support

• Discussion of higher-kinded types: many mainstream languages (e.g. C#, Java) can implement specific monads and flatMap-style operations but cannot express the generic Monad typeclass cleanly.
• Examples show how C#, Kotlin, Scala emulate Functor/Monad behavior with Select/flatMap and how syntax sugar (LINQ, for-comprehensions) desugars directly to these operations.
• Multiple comments stress that Haskell’s static types + referential transparency make monads especially powerful for “effect typing” (knowing from the type which effects can occur).

List monad and nondeterminism

• Several point out that the standard list monad models bounded nondeterminism: a List<T> can be seen as the set of possible results; flatMap corresponds to branching and combining all possible paths.
• Detailed explanations link this to the usual theoretical CS notion of nondeterministic computations and NFAs (states as sets/lists).

Monads: containers vs effects / recipes

• Some argue “a monad is not a container”; thinking in terms of “unwrapping” values is often misleading, especially for monads like IO or function types.
• Others defend a “wrapper with additional state/effect” intuition (e.g., Maybe, List, Promise) as a useful mental model, as long as it’s understood that not all monads literally contain extractable values.
• The article’s “container vs recipe” framing is broadly liked, with caveats that “recipe” (sequence of effectful steps) better captures many monads.

Meta: pedagogy, overload, and frustration

• Several readers say monad explanations that pile metaphors (burritos, containers, lists) without showing real problems they solve only add confusion.
• Some describe finally “getting” monads once they realized list, Maybe, and IO all share the same shape of composition, not the same meaning.
• There’s recognition of “monad tutorial fatigue”: many links to prior posts and even a “monad tutorials timeline”; some feel the obsession is more cultural than practical.