[Haskell-cafe] Better writing about Haskell through multi-metaphor learning

[Joachim Durchholz]

Am 19.09.21 um 23:04 schrieb Richard Eisenberg:
> Popping up a level: for me, the value in these ideas is not their precision, but rather their familiarity. Give me intuition first, correctness later.
> 
> [...] Another example: we now know that object do not accelerate parabolically under the influence of gravity, because of general relativity. But general relativity is hard, so we still teach about parabolic curves for objects in freefall. Once a student knows more physics, they can return and refine their knowledge.
> 
> So can it be with Haskell. We sometimes get so caught up in being "right" and precise, that we forget that it is sometimes useful to paper over some details for the sake of intuition.

I agree that you need to have a first working model initially, with all 
the details coming later.

In the case of monads, I think that the usual initial model (a monad is 
a pipeline) is insufficient even at the novice level.
I'll argue for that from observation, and from reasoning.

Observation: Many novices come up with questions about monads. It's the 
number one stumbling block, and the thing that keeps people turning away 
as in "that's all too mathematical".
Compare this with Java:
	public static void main(String... args)
which floods the user with four advanced concepts (public, static, void 
results, varargs parameters), yet gives rise more to ridicule than 
frustration.
More importantly, each of these concepts immediately points to something 
that you can explore and understand separately.

Reasoning:
Most expositions of monads start with some kind of pipeline concept.
The problem with that is that it's misleading without giving people a 
clue where they're going wrong.
E.g. think "pipeline" and hit Maybe and Error. These concepts don't 
"look like" a pipeline, more like a variation of function composition - 
but why is it then a monad instead of function composition?
List is even more difficult to fit into the pipeline methaphor. Using 
List's monad properties is mostly interesting for tracing all cases of 
nondeterministic behaviour, but you very rarely do that in code, so it's 
not a big deal - but it still is a cognitive dissonance for the student, 
a sore spot in the mental model.

Even before these two, you see IO. You can easily get away with the 
pipeline model at first when you just do output, but as soon as you have 
input and decisionmaking (i.e. the output becomes a decision tree, each 
run of the program following one path from the root to a leaf - actually 
it's a DAG and nonterminating programs don't necessarily have leaves), 
the pipeline model is not a good fit anymore.
(I very much like David Feuer's idea how to teach angles in terms of 
"turns". It carefully avoids putting the student at a wrong track. Since 
radians are taught waaay after division by fractions, even the division 
by an irrational number that you need to "explain" radians isn't such a 
big deal - i.e. it also orders concepts in an order where each concept 
can be explained based on things the student already knows.)


Just my 2 cents, and based on more thinking than programming, so it may 
not be worth much.

Regards,
Jo