There's a problem in the teaching of monads that containers are the easiest ones to explain, but also the least interesting in practice :)
>To make monads interesting you have to show specific instances of monads like Maybe.
While individual monads are useful by themselves, the _concept_ of ‘monad’ is only interesting once you can generalize over it. If you can't write (interesting) code that's generic over an interface, there's not much point in doing the work to generalize from the specific instances of that interface. But part of why monads are interesting is that it turns out a lot of natural ‘sequential’ code that one might write in a procedural language actually generalizes naturally to an arbitrary monad, in ways that make the resulting code drastically (even unintuitively, for someone used to thinking in terms procedural code just meaning single-valued strictly-ordered sequencing) more powerful.
I think to me the idea that talking about monads as monads is only useful once you can generalize over monads, and HKTs are necessary to effectively generalize over monads (‘effectively’ meaning without undue cognitive or syntactic load), is a much more likely explanation than the slightly uncharitable one that people are pulling in HKTs as a smokescreen for bloviation.
> In some cases you need to depart from monadic purity pretty quickly to get useful behavior
One of the main motivations for introducing the monad interface to semantics, and thence to programming, is that notions like stateful, multivalued, or asynchronous execution that are ‘impure’ (i.e. outside the model) when considering a program as a function (Scott semantics) can in fact be reasoned about in a ‘pure’ way by adding a monad to the codomain of the function. So things like `Promise` are not ‘departing from monadic purity’, they're good and true examples of upstanding monads :) Even ‘naughty’ monads like Haskell's `IO` can notionally be thought of as pure — the fact that the interpretation of the monad is done by a magical external runtime and not by pure functional code that passes the world around is more an artefact of the external code of the OS/computer you're running on, and you can think of it as a sort of implementation detail/performance optimization.
> "area under the curve" or "inverse of differentiation" are way better as they have immediate utility and operate in the context of what the learner already most likely knows.
Fully agree with you there, but you don't then try to explain algebraic topology in terms of the area under the curve. You can (and generally should!) start from a point the reader is already familiar with, but it's a perfectly defensible decision to go from there on a path through intermediate concepts that make explaining the target notion easier, rather than throwing the reader straight into the deep end. Of course the choice of how long or short the path should be (and therefore how big the jumps one expects the reader to make) is a decision that is the writer's responsibility.
>To make monads interesting you have to show specific instances of monads like Maybe.
While individual monads are useful by themselves, the _concept_ of ‘monad’ is only interesting once you can generalize over it. If you can't write (interesting) code that's generic over an interface, there's not much point in doing the work to generalize from the specific instances of that interface. But part of why monads are interesting is that it turns out a lot of natural ‘sequential’ code that one might write in a procedural language actually generalizes naturally to an arbitrary monad, in ways that make the resulting code drastically (even unintuitively, for someone used to thinking in terms procedural code just meaning single-valued strictly-ordered sequencing) more powerful.
I think to me the idea that talking about monads as monads is only useful once you can generalize over monads, and HKTs are necessary to effectively generalize over monads (‘effectively’ meaning without undue cognitive or syntactic load), is a much more likely explanation than the slightly uncharitable one that people are pulling in HKTs as a smokescreen for bloviation.
> In some cases you need to depart from monadic purity pretty quickly to get useful behavior
One of the main motivations for introducing the monad interface to semantics, and thence to programming, is that notions like stateful, multivalued, or asynchronous execution that are ‘impure’ (i.e. outside the model) when considering a program as a function (Scott semantics) can in fact be reasoned about in a ‘pure’ way by adding a monad to the codomain of the function. So things like `Promise` are not ‘departing from monadic purity’, they're good and true examples of upstanding monads :) Even ‘naughty’ monads like Haskell's `IO` can notionally be thought of as pure — the fact that the interpretation of the monad is done by a magical external runtime and not by pure functional code that passes the world around is more an artefact of the external code of the OS/computer you're running on, and you can think of it as a sort of implementation detail/performance optimization.
> "area under the curve" or "inverse of differentiation" are way better as they have immediate utility and operate in the context of what the learner already most likely knows.
Fully agree with you there, but you don't then try to explain algebraic topology in terms of the area under the curve. You can (and generally should!) start from a point the reader is already familiar with, but it's a perfectly defensible decision to go from there on a path through intermediate concepts that make explaining the target notion easier, rather than throwing the reader straight into the deep end. Of course the choice of how long or short the path should be (and therefore how big the jumps one expects the reader to make) is a decision that is the writer's responsibility.