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

[David Feuer]

FYI, it's not my idea; I just figured I could slot it in. I have no idea
what pipelines night mean in this context. Something to do with Unix
utility composition?

On Mon, Sep 20, 2021, 2:05 AM Joachim Durchholz <jo at durchholz.org> wrote:

> 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
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210920/3a04acf0/attachment.html>