It seems like your entire article would make a lot more sense if every instance of the word "monads" was replaced with "the IO monad". There are other monads, you know.

Yes, I do know, but please think about where you are reading this and the target audience, as well as my admission to being a 'failed' Haskell programmer. You should not expect deep and authoritative discussion on Haskell in this environment :)

It seems like an especially useless abstraction to be making if ... you're coming from an imperative background, which is ... like working in the IO monad all the time.

That was and is pretty much exactly my point. I'm aware that the bits I've elided make the statement much less definitive than I did, and within that lies the power of the monad abstraction, but that brings me back to my final question above, which can be paraphrased as: Do I, as a jobbing programmer need that power. It may be a endlessly fascinating subject for the academic/language designer, but does it really give the working stiff something that he does not already have in other languages.

Isn't there a dichotomy between these sentances from your first and last paragraphs?

• "(In particular, the IO monad is primitive in Haskell by necessity, but it's the only monad like that.)"
• "I/O is handled by a monad in Haskell not because it's absolutely necessary that it be handled by a monad, but because it's possible,"

From this point I'm going to have to resist the temptation to get drawn into arguing about the efficacy and effectiveness of Haskell (here). This is the wrong place, and I am not qualified. I've already allowed myself to over-extend my reach, and I'll probably regret doing so. But I'd be willing to continue and would relish the opportunity to learn) off-post via email, but not here.

However, your arguments above remind me of a post I made some time ago. Please do not take offense. Nor think I am aiming the first line (or most of the rest of it) at you. And definitely ignore the context in which it was posted. But...there is one bit that I think is applicable, though even that isn't worded quite right for application in this context.

...and succeeded in re-creating your system using theirs, will you be in a position to counter their objections to your system, in their own terms.

Only then will you have the ammunition with which to prove the veracity and accuracy of your system, in a way such that they can accept it.

What I'm trying to get at here is that if you 'buy in' to the whole Haskell experience--from the efficacy of Hindley-Miller and functional programming, and purity up--then everything you say above, and all the deep discussions and treatise and papers in the Haskell world may (probably) make sense.

But, if you are coming from a long and deeply imperative background as I am, and with respect, the vast majority of the worlds programmers are, then without the mathematical grounding to fully appreciate the full implications of HM, and the category theory underlying monads, it does seem like, as you put it above, " an especially useless abstraction".

The problem with the rich and extensive set of information available on Haskell, and monads in particular, is that for the most part, it assumes a deep understanding of those underlying (and often obscure) mathematical concepts. It is often also somewhat pejorative and condescending ("... or what computer scientists call nondeterministic computations.") of those that do not come from that background.

I'm not offended by that. It may well be true that I am either too old and set in my way, wrongly educated, or just too stupid, to ever make the journey of enlightenment required. Required to allow me get beyond the feelings of frustration when I encounter something (in Haskell) that seems clumsy, over-complicated or outright impossible, when I know that I could do that same thing in any of a dozen other languages in my sleep.

You'll note (or rather I'm going to do it for you), that I never said that Haskell didn't need or benefit from monads. Indeed, I said the exact opposite. And when I asked "Are monads worth [the bother]", I was doing so from the perspective of someone who has written hundreds of programs and 10s or 100s of thousands of lines of code (guesstimate!), without ever once needing 'monads'.

And to explain that monads are necessary "because they ensure referential integrity", isn't enough. Because I've written those same number of programs and lines of code without needing that either. And that's where the quote from my old post above comes in.

Until I can understand how the provision of the same facilities Haskell has would benefit my programs in Perl (or C, or Java, or ...), then it's just not possible to see beyond the argument that Haskell only has those facilities because Haskell needs them.

And Haskell only needs them because it makes certain (dogmatic) decisions about the need for purity, referential integrity, strong typing and provability. And all of those are just too easy to dismiss as unnecessary and/or non-beneficial.

(I can see) There are several aspects of Haskell that are desirable, but as a language it is impossible to have those bits without taking all the rest, and the rest imposes such burdens upon the development and thought processes, that I have to question whether they are worth it.

Don't misunderstand me. I know (for example) that proficient Haskellers tend to win against-the-clock programming competitions with unerring regularity, almost to the exclusion of all other languages. So i know that, in the right hands, Haskell very much challenges and often surpasses Perl at it's own game in the programmer productivity stakes. But, how many expert Haskellers are there?

And how many of those programmers earning a living on a daily basis in other languages have the (maths theory) background and nouce to make the transition to using Haskell? And if they have to acquire a good understanding of category theory and type system theory and dog knows what else in order to see the benefits of the transition to using Haskell, how many of them are going to have the incentive to try?

Until someone can explain its benefits to them in their own terms, the incentive to learn enough to understand the concepts in Haskell's terms, and those of functional programming purity, are minimal. Mostly just curiosity, which is easily 'cured' by work pressures, or condescension, or apparently self-describing, self-confirming 'belief' systems.