[Haskell-cafe] Haskell's "historical futurism" needs better writing, not better tools

Thu Sep 16 14:34:09 UTC 2021

  I strongly believe the best study strategy is to be unfaithful to any
source or subtopic. When I want to learn something, I study whatever aspect
of it holds my interest, for only slightly longer than it continues to do
so. If I continue to want to learn a topic, but lose interest in a
particular source or subtopic, it's important to stop that particular
avenue. Otherwise I'll lose motivation for the topic as a whole.

  The result is that, while I never learn (say) a language completely, I
generally learn enough to do whatever I was trying to do. (Sometimes I
learn enough to decide it's too hard -- and for cases in which that's bound
to happen, the quicker the better.)

  Almost nobody learns any language completely anyway, and most of those
who do could have used their time better. Sacrifice is a superpower.

On Thu, Sep 16, 2021 at 9:09 AM Richard Eisenberg <lists at richarde.dev>
wrote:

> I just want to pipe up and say I'm not comfortable with this response.
> When I feel this way about writing on a forum, I normally contact the
> author in private, but I think posting publicly here has its merits. I'm
> hoping that the long correspondence AntC and I have had -- often with
> opposing viewpoints but with mutual respect -- with withstand this email.
>
> Michael posted here expressing frustration with his experience learning
> and using Haskell. In my opinion, he has spent too much time reading older
> papers, written by experts for experts -- which Michael is not. I do not
> fault Michael for this: these resources are sometimes what appear when
> searching, and we as a community have done a poor job marshaling our
> educational resources. (Michael, I just thought of a resource you might
> find useful: http://dev.stephendiehl.com/hask/ is an oft-linked resource
> attempting to do that marshaling. I am not vouching for it here, per se,
> but I know others have found it useful.)
>
> However, Michael very specifically said that "just learn lambda-calculus"
> was not helpful for him, and so I think it's unhelpful for someone to
> respond with "just learn lambda-calculus". There are a number of other
> statements in the email below which could be seen as belittling -- also not
> helpful.
>
> Instead, I wish that we, as a community, could take posts like Michael's
> at face value: this is the experience of someone who wants to learn
> Haskell. While some of the conclusions stated in that post are
> misunderstandings, it is not the sole fault of the learner for these
> misunderstandings: instead, we must try to understand what about our
> community and posted materials induced these misunderstandings, and then
> seek to improve. Many people in Michael's situation may not have posted at
> all -- and so this kind of information can be very hard to get.
>
> Michael, I have no silver bullet to offer to you to try to help you here.
> I do tend to agree with AntC that you have developed some misconceptions
> that are hindering your continued learning. The terminology actively hurts
> here. (To be fair, the first Haskell standard pre-dates both Java and C++,
> and so one could argue who got the terms wrong.) For my part, I am trying
> to help with this situation both by trying to improve error messages, and
> though my support of the Haskell Foundation's Haskell School initiative (
> https://github.com/haskellfoundation/HaskellSchool). These will take time
> to grow, but my hope is that a future person like you will have an easier
> route in.
>
> In the meantime, I implore us to take all expressed experiences as exactly
> that: the experience of the person writing. And if they say they don't want
> X, please let's not feed them X. :)
>
> Richard
>
> On Sep 16, 2021, at 12:53 AM, Anthony Clayden <anthony.d.clayden at gmail.com>
> wrote:
>
> Hi Michael, oh dear, oh dear, oh dear.
>
> The seeds of your confusion are very evident from your message. How to
> back you out of whatever deep rabbit-hole you've managed to get your head
> into?
>
> >  ... Your average reader (already a programmer) would be better served
> by a comparative approach: Here's how to say something in a couple of
> other programming languages, here's how to say something roughly
> equivalent in Haskell -- BUT, here's how it's subtly different in Haskell.
>
> No. Just no. Haskell is not "subtly different" to (say) Java in the way
> that C++ or C# are different. (I'll leave others to judge how subtly
> different they are.)
>
> Haskell is dramatically and fundamentally different. You can't just
> 'translate' an algorithm from OOP to Haskell. Many newbies try, and there's
> many tales of woe on StackOverflow. Just No.
>
> I really don't know how you could have got any experience with Haskell and
> say "subtly".
>
> I suggest you unlearn everything you think you know about Haskell, and
> strike out in an entirely different direction. The best approach would be
> to spend a few days playing with lambda calculus. (That's what I did before
> tackling Haskell.)
>
> > (I've actually been curtly informed on the beginners' list -- yes, the beginner' list! -- that my problems of comprehension can be solved simply: "Learn lambda calculus.")
>
>
> Lambda calculus is an excellent place for beginners to start. What could
> be easier to learn? It's certainly easier than grokking a Turing machine;
> and much easier than Haskell: less than a handful of primitives yet can
> compute anything computable.
>
> > And since the concepts are seldom described in concrete enough and
> time-honored programming language terms (by comparison to other
> programming languages)
>
> I'm guessing that the concepts you're talking of simply don't correspond
> to anything in time-honoured (procedural) programming. Anybody writing
> about Haskell (including anybody writing the User Guide) assumes a base
> level of understanding of Haskell. You've clearly veered off the track and
> haven't yet reached base. Remember the User Guide builds on top of the
> Language Report.
>
> (On the point of 'time-honoured': lambda calculus is almost exactly the
> same age as Turing machines. The first well-known programming language
> using lambda-calculus ideas (LISP 1966) is almost exactly the same age as
> the first OOP language (Simula 1967). Which is the more time-honoured?)
>
> You do have a point that the terminology in Haskell is often mysterious
>
> > [SPJ said] F# had settled on the term "workflow" instead of "monad", and
> he felt this was wise.
>
> Yes many have yearned for a more warm-and-cuddly term than "monad". But
> the terminology barrier starts before that.
>
> Haskell typeclasses are not 'classes' in any sense recognisable from OOP.
> There are no objects, no hidden state, no destructive assignment. We might
> go back to February 1988 when a strawman for what became typeclasses used
> OVERLOAD/INSTANCE.
>
> AntC
>
>
>
>
> _______________________________________________
> 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.
>
>
> _______________________________________________
> 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.

-- 
Jeff Brown | Jeffrey Benjamin Brown
LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>   |   Github
<https://github.com/jeffreybenjaminbrown>   |   Twitter
<https://twitter.com/carelogic>  |  Facebook
<https://www.facebook.com/mejeff.younotjeff>  |  very old Website
<https://msu.edu/~brown202/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/e6a8f29b/attachment.html>