[mikorym]

According to one of my lecturers, who knows both Haskell and is a Category Theorist, and according to some of my fellow students at the time, monads in functional programming should not be seen as strict versions of the category theoretical concept.

The key concepts for FP are: you are able to reference system state, you are able to leverage composibility better than non-FP languages, you can abstract and prove things around how your program should behave.

I have a copy of Category Theory for Programmers that I haven't read in earnest, but I would think that the section on monads can clarify the main differences between the mathematical monad and the FP monad.

[jhanschoo]

> According to one of my lecturers, who knows both Haskell and is a Category Theorist, and according to some of my fellow students at the time, monads in functional programming should not be seen as strict versions of the category theoretical concept.

Indeed, e.g. lists are monadic, but it is more natural to talk about maps from one list to another, and folding.

But neither is a fundamental monad operation. The natural operation for monads in the example of lists is flatmap, which takes in a function (X -> List Y), and a List X, and returns a List Y. The `map` function is a less powerful sibling of flatmap, and the `fold` operation is more powerful and general than flatmap.

So whereas CT monads distinguish one (admittedly very powerful) notion of composability, monad-like notions in FP may find other notions of composability more natural.

Of course, the main draw of using monads in FP is with the way it quarantines off state and context.