>I think it's much more effective to start with learning functors and applicatives before monads. I'm surprised at the number of tutorials aimed at teaching people monads who don't yet understand the more basic type classes.

I agree, we did this in our book. We actually decomposed it pretty aggressively - http://haskellbook.com/progress.html

There is a point at which you can just follow along with the types as you learn Monads, but it's not terribly satisfying without context and still requires understanding _the types_. That's pretty hard to do if you aren't comfortable with higher kinded types and typeclasses. Functor and Applicative let you break the problem down a bit more. We do Monoid and Semigroup before Functor so they get accustomed to seemingly very abstract typeclasses before coping with higher kinded types + seemingly-abstract typeclass. Prior to _Monoid_, we explain kinds and higher kinded types.

This approach has made it so the book works a lot more effectively; frequently, but also makes it longer. Lots more code, examples, and exercises.

I've wondered that myself. I think the reason might be monads are used to represent IO computations and state mutation so people are interested in jumping straight into that. Honestly I use functor as much/more than I use monad in my day-to-day code which supports your statement here.

Coming at this from a mathematician's perspective, it's complete madness to learn what a monad is before learning what a natural transformation (and therefore a functor) is. I would also consider it somewhat eccentric to do monads without learning what an adjunction is, since adjunctions are basically why we're interested in monads in the first place.

Having been mildly disappointed by the simplicity of monoids, after intimidation from the complexity in maths, i expect that something like an adjunction is something already known to a commoner in any case, just that the vocabulary, particaularies and relations to the concept in question are not always obvious.

Monoids really are simple things. Monads are a bit less so, but they're still fairly simple objects (as evidenced by the fact that they have a short description, "monoids in the category of endofunctors", even if most people don't know what that means).

Adjunctions turn up all over maths, but I've been trying for a while to come up with an example which programmers (as opposed to mathematicians) would quickly understand. Broadly speaking, they represent "the leanest way to add a particular structure to something", but of course that's pretty useless for understanding them!

Adjunctions aren't highly relevant to programming. Monads in programming have much less category theory than monads in math.

The significance of monads in programming is entirely because of the adjunction between the category of types and "pure" functions and the category of types and "monadic" functions (i.e., the Kleisli category of the monad). A monad is used to encode the latter in terms of the former via the Kleisli adjunction (whereby monadic maps from FX to FY correspond to pure maps from X to GFY, with the monad GF thus arising from an adjunction F -| G [where F can be taken to be identity on objects in the case of interest]).

If you're going to talk like that, stay far, far away from anyone who is trying to learn monads.

I assert that most people coming to Haskell do so because "I hear Haskell and/or FP is cool, I'll try to learn it" rather than "Category theory is so cool, wouldn't it be awesome to program that way". What you said may be true, as the theoretical foundation for why monads are useful, but for someone trying to learn to program in Haskell, what you said is the last thing they need to learn about monads.

That comment of mine wasn't the spiel I'd give to someone first trying to learn about the typical use of monads in a programming context, any more than I'd lecture a beginning programmer on the general theory of commutative rings while introducing integer and floating-point arithmetic (the latter not actually comprising a commutative ring...).

But teaching the use of monads to unfamiliar programmers wasn't my goal in that comment. I was just pointing out the accurate response to "Adjunctions aren't highly relevant to programming".

What if one simply says that a monad describes a pattern of morphisms composition ? Adjunctions being the plumbing ?

(honest question, just trying to find a simple, grokkable definition)

Fair enough. There's a place here for technical accuracy all the way down.

I'm not very familiar with category theory and can't really make heads or tails of what you're writing there, but I think the idea behind the statement that "adjunctions aren't highly relevant in programming" is to say that there isn't a huge amount of immediate utility of adjunctions as a programmer. On the other hand, programmers use monads all the time (even if they don't realize it, which is the most common case, as the monad in question is the evaluation of the imperative language they're writing in). Of course, to be honest, I wouldn't know an adjunction from a hole in the ground, so perhaps the same is true for adjunctions -- but I've never heard of them so I'm assuming that's not the case. Either way, what makes monads worth understanding is precisely how useful they are in day-to-day, real-world programming, and in particular understanding how they're used in Haskell is practically essential for understanding almost any extant Haskell code.

The purpose of that comment is to note precisely the same thing applying to adjunctions as you note applying to monads: programmers use adjunctions all the time even if they don't realize it.

"I've never heard of them so I'm assuming that's not the case"? Well, hey, most programmers have never heard about monads either. Explicitly having heard of a thing is, by definition, not a requirement for it to be something which one "use[s]... all the time (even if they don't realize it...)".

[I'm not saying everyone needs to go out and learn about adjunctions. But they're in exactly the same area as monads in terms of their applicability as a concept to programming. It's weird to consider the one a down-to-earth, comes-up-all-the-time notion and the other some airy-fairy academic construct.]

I really appreciate this description. Always nice to see the "actual" definitions instead of "it's like a thing you can map over."

I initially had problems understanding monads in Haskell having come from a math perspective.

Hi, author here. Thanks for the feedback. I definitely get your point. I thought about it and there are a few reasons I went the way I did. 1. I decided that functors are straightforward enough to not really need significant special treatment. 2. Applicatives are much less commonly used than monads (see IO etc), so I thought it would be more desirable to hit the bigger use case first without getting side tracked on applicatives. 3. I feel this progression kind of has history on its side since Applicative wasn't a super class of Monad until very recently.

That being said, I'm very open to being convinced otherwise and pull requests carry a lot of weight with me. If someone reorganized the material in the way you suggest and it had a nice flow, there's a decent chance I would accept it.