1. I perhaps forgot to mention a key thing about the enlightenment process. Most of the people being
asked the question are those further down the path, but not further-down by much. Journeymen, not masters.
A journeyman is someone who has acquired all the micro-skills they were missing, and has thus gone on to achieve some level of intuitive grasp of the enlightenment they sought. They "grok" the skill.
A master is someone who has gone back and thoroughly weeded their mental garden of the micro-skills they started with and took for granted, and have begun (though perhaps not finished) replacing those with conscious learnings. The master desires to attain conscious handles onto each and every part of the mental schema or process they seek to understand, in order to understand the enlightenment-requiring mental skill as a system, rather than as a simple intuition.
A journeyman has a sense that they know the answer—that they "are enlightened"—and this sense works well enough to guide them when they seek to use the mental skill they sought to acquire. But, because they do not understand the enlightenment-requiring mental skill as a system, only as an intuition, they can give an apprentice on the path no answer that will satisfy them. This is the "gallows humour" stage of the path.
Yes, masters of the path will be able to guide apprentices. Zen koans are written by masters, and they are no gallows humour; they tilt the world enough to allow you to catch sight of the micro-skills the master was attempting to convey. (In the modern world of analytic philosophy, koans might even have a hope of being displaced by jargon-laden explanations that can be drudged through to bash the concept into one's head, like a maths textbook. That doesn't sound exciting, but it is!)
Light Table is such a koan, created by a master of the path of living-memory-image reflective systems, seeking to "tilt" as many parts of the system that Smalltalk is into the light as possible. (Granger's trick was contrasting those parts to a backdrop of regular, ugly concepts like Javascript and Electron that aren't part of the enlightenment-inspiring system. The concept-handles come clear at the visible seams of the Light Table system. Whereas, in Smalltalk itself, the seams aren't visible, because the system is coherent. You can't see the muscles of the perfect average face; it's too coherent to dissect.)
Putting this another way: most people who might be asked about something aren't teachers with education degrees. They're just students who already learned something and want to share what they learned. They fail because the thing is hard to share, and they don't have the skills about teaching required to realize what's making the thing hard to share and to fix it. (Those that do have such skills, but don't have the time to apply them to the concept—dissecting it and re-building it in a teachable-to-others form—usually just keep silent, rather than attempting to share their learning.)
> Haskell['s journeymen] are such failures [to teach the required micro-skills] even in the face of an audience who has previously undergone such a paradigm shift.
Ah, but have they? Many people have a natural mind for software engineering. They take for granted the concepts inherent in procedural code execution on a CPU or virtual machine; in parsing and lexing; even in pseudo-paradigms like OOP.
Indeed, it is the rare software engineer who actually experienced any paradigm shifts regarding Computer Science (for those of us that took a degree in it.) Usually it's "easy"—meaning natural—for those of an analytical mindset.
All, perhaps, except for that one class you have to take at the beginning of a CS curriculum, Discrete Maths. A lot of the SwEng "naturals" struggle at that. Because Discrete Maths is not the same thing as CS. Discrete Maths is, in fact, maths.
Mathematicians are used to paradigm shifts/"englightenments" (i.e. learning systematic skills requiring working knowledge of many micro-skills). Each subfield of mathematics is essentially named for the systematic skill required to comprehend work done under its aegis. Mathematicians who read work in various sub-fields, are used to quickly achieving a journeyman's competence in the relevant systematic skills. Mathematicians who specialize, who enter a sub-field, must necessarily become masters, if they have any hope of building upon that work. They must understand the required skill fully. (They must, by cute analogy, be able to build their Light-sabers from scratch.)
Most software engineers—including Haskellers—are not mathematicians. They have, other than that one time in Discrete Maths, never experienced the feeling of climbing toward an enlightenment. Even then, Discrete Maths is often the lowest grade for a lot of new CS students. They don't yet have this meta-skill of climbing toward enlightenments—of throwing themselves hard at formalized jargon using textbooks and references in an attempt to build a new systematic schema in their brain in just a few days. And they are almost never told that this is the true skill that their Discrete Maths course is there to impart into them. It's not about learning graph theory or whatever; that, just as much as a class on Operating Systems or VLSI or whatever else, is a practical, concrete skill for a software engineer. The Discrete Maths class in a CS program is about learning how to quickly learn those kinds of concepts. It's about discovering that these mental gulfs exist, and learning the skills required to cross one.
If only it was taught as such ;)
The reason Haskell is uniquely bad, here, is that Haskell was—perhaps problematically—constructed by mathematicians, people who had already crossed one such gulf. Haskell's design and ecosystem "reflects" enlightenment on category theory, somewhat like Smalltalk "reflects" enlightenment on living-memory-image OOP. Neither system teaches those skills, though. You don't need to cross the gulf of category-theory to intuit Haskell as a journeyman; you only do if you want to have the appreciation for the "coherent shape" of Haskell required to make coherence-preserving modifications to its feature-set.
---
The long and short of the way to communicate all the Haskell "stuff" efficiently, not just monads, is to:
1. give the learner the meta-skill of Being A Student Of Mathematics (i.e. becoming a journeyman in new systematic skills by poring over textbooks and doing problems);
2. throw a Category Theory textbook at the learner, who is now equipped to digest it.
Anything less is laziness—though not necessarily on the part of the teacher ;)