> Understanding the very generalized algebraic monad helps you to understand the nature of encapsulating effects and adding complexity to categories through layering.

I don't see how the general notion of category theoretical monad helps with this. In fact it's debatable whether the notion of monad is really the right treatment for universal algebra at all. Lawvere theories are much simpler and capture almost all of what you need. See: https://www.dpmms.cam.ac.uk/~martin/Research/Publications/20...

> Knowing the relationship between `Monad` and `Category` the type classes is almost never useful in programming Haskell.

I disagree. I use (<=<) all the time. It's basically (.) with the Kleisli wrapping and unwrapping done for you.

I'm not arguing that (>=>) isn't great or that Monads are better than Lawvere Theories, nor that what you presented isn't interesting and useful. Instead, I'm responding from the point of view of someone who read a lot of terse accounts of what typeclass Monads were back when I was first learning them.

The category law account for the Monad laws is useful once you've already learned to think categorically, at which point a full definition is great and provides indications of the next places to examine. Defining that a "Monad is really a Category k with an identification between k a b and a -> k () b" seems most useful to people who could already write "Monads Made Difficult", but not those who are trying to struggle to see how all these connections play out.

Monads Made Difficult is difficult, but lays the groundwork for a lot of the categorical machinery that forms the environment where Monads were born. That's important.

I'm a bit confused.

Are you saying that "Monads Made Difficult", is useful to "those who are trying to struggle to see how all these connections play out"?

My position is that it's definitely not. I don't think it's even really useful to experts, because, wait for it ... Haskell Monads really have very little to do with category theoretical monads! If all you want to do is to know how Haskell Monads work than I think that level of generality is unhelpful. If, on the other hand, you want to learn category theory then this is a fine approach :)

(NB I'm not claiming my article is for beginners either)

In summary, I think the article is a great way to learn about category theory by building on your knowledge of Haskell, but it is more complicated than necessary to help with understanding Haskell Monads.

I can agree with that. I suppose I believe, from my own personal experience, that a categorical approach to monads, even if they are distinct from Haskell `Monad`s, is a very good way to learn more advanced concepts in understanding Haskell Monads.

I don't think either article is great place for a beginner, but instead am coming from a point of view toward learning "advanced" functional programming and getting a flavor for categorical/squiggol style thinking. To me, it was greatly helpful to just see the pure math approach and then realize Haskell Monads as a simple example and less useful to see categorical concepts played out in the simplified Haskell domain.

Categories just don't make nearly as much sense as objects when all you see them as is a convenient way to talk about composition rules. They're dramatically powerful when you connect them to preorders, databases, graphs, or homology. My biggest moment of categorical bliss came from seeing the Paths monad on graphs, even though that is far removed from the programming domain.

Databases?

Yeah, look into work by David Spivak. Category Theory for Scientists is a long tutorial he wrote.

> I don't like your take because it refuses to take that deeper dive into the mathematical Monad, despite alluring to it.

Mathematics is quite alluring, but the word most people would use there is 'alluding'.

Hah, Freudian slip, perhaps?

I suspect even more would use "eluding".