[Haskell-cafe] Haskell-Cafe Digest, Vol 217, Issue 16
Andrey Sverdlichenko
blaze at rusty.zone
Fri Sep 17 18:25:23 UTC 2021
> Haskell's big problem right now is adoption.
I'm not quite sure this is a problem. Haskell and its libraries are
designed around math concepts, as opposed to CS concepts (semigroup vs
IConcatenable). Learning it all but requires learning some algebra as well,
thus a lower adoption rate is expected.
Personally, I consider this math requirement a great educational benefit:
raising the level of abstraction from "container" to "monoid" helps to make
better design decisions. It may be an obstacle for someone who wants
quickly put together a new product, but this is the wrong tool selected for
a job. A book like "Category theory for programmers" (that exists) and
"Algebra for programmers" (that I don't know about) may help with learning
and provide practical examples, but explaining math without using math
words sounds like a futile attempt.
On Fri, Sep 17, 2021 at 12:58 AM Michael Turner <
michael.eugene.turner at gmail.com> wrote:
> "The seeds of your confusion are very evident from your message".
>
> The seeds of your unsubstantiated assumptions about me are very
> evident from yours.
>
> "You can't just 'translate' an algorithm from OOP to Haskell"
>
> Wow, I'm either "trying to translate Haskell to C++" (someone else,
> above) or trying to translate C++ to Haskell.
>
> I'm actually doing neither. I started by trying to understand this:
>
> https://www.stwing.upenn.edu/~wlovas/hudak/aug.pdf
>
> (And no, just because Haskell is great for writing little
> special-purpose programming languages does not automatically mean it's
> up to snuff for handling natural language.)
>
> I'd originally hoped to fully understand the rather short program in
> that paper (full code, in two versions, elsewhere on Paul Jones aca
> dite) by getting it to run again, then commenting the code as I began
> to understand it. And then, on to more important issues for a fuller
> Haskell implementation, issues described here
>
> https://www.aclweb.org/anthology/C94-2137.pdf
>
> and here
>
> http://www.lacus.org/volumes/23/22.sypniewski.pdf
>
> Both of which are references I dug up and supplied here
>
> https://en.wikipedia.org/wiki/Applicative_universal_grammar
>
> as I took the Wikipedia article from stub status to something less
> stubby -- it actually started in this state:
>
>
> https://en.wikipedia.org/w/index.php?title=Applicative_universal_grammar&diff=prev&oldid=1020447173
>
> The ASCII-art diagrams you see there are output from code that I've
> gotten working again.
>
> I learned about lazy evaluation in college, when I got interested in
> how Lisp might implement it. I'm very familiar with the arguments for
> purity, especially from learning Erlang some years ago (during which I
> wrote my share of accumulator-based tail-recursive functions.) I
> prefer static typing but hated the way C++ templates extended the
> concept, mostly because the syntax error messages were so bad for so
> long. My career includes a time in the late 80s when the kind of
> computing power we have in our phones now with multicore processors
> filled a box of hardware too heavy to lift. This was at a startup
> where the founder was substantially inspired by this stream-oriented
> single-assignment language:
>
> https://en.wikipedia.org/wiki/SISAL
>
> I started programming at 15. It's been a very rare year, even after
> leaving the software profession, when I didn't write at least some
> code, learning new things in the process. Which means I've been
> looking at programming languages and how to implement things at the
> most appropriate level of abstraction possible for just a few months
> shy of fifty years.
>
> The arguments here are following a familiar pattern, one I see in
> discussions of everything from programming to government policy.
>
> (1) I disagree with someone
> (2) This person instantly assumes I must be ignorant of what they know
> (3) They start Mansplaining It All To Me.
>
> This is particularly irksome when the person is actually considerably
> more ignorant of the subject than I am.
>
> I'm still ignorant of most of Haskell, to be sure. However, I'm not
> ignorant when it comes to writing. (Published articles on request.) A
> great deal of what's written about Haskell, usually with very good
> intentions, has proved useless to me. Have I had a stroke that leaves
> me apparently unharmed, but actually no longer able to absorb a
> different programming language? Was I always just too dumb to learn
> Haskell? Somehow, I think it's more related to the writing.
>
> To some extent the community seems to recognize there's a problem --
> e.g., the Monad Tutorial Explosion. I finally got (most of?) what
> monads really mean for practical programming when none other than
> Simon Peyton-Jones said F# called a very similar construct "workflow,"
> a word he likes. Wow, plain English instead of a mathematical
> abstraction that, in the math introductions, looks weirdly clunky to
> me, if anything, but, in any case, very hard to relate to writing
> better code.
>
> Lambda calculus? I have vague memories of Eugene Lawler
>
> https://en.wikipedia.org/wiki/Eugene_Lawler
>
> covering it when I took computing theory from him. And again, when I
> was grading computing theory homework for this required course for
> graduate students (for their prelim exams) for Richard Lipton
>
> https://en.wikipedia.org/wiki/Richard_Lipton
>
> in the fall term of 1980 at U.C. Berkeley.
>
> It's not that I'm too stupid to learn lambda calculus. It's that I
> seriously doubt that refreshing my memory on the details is going to
> add significantly more to my grasp of functional programming in
> Haskell.
>
> I disagree with some people here. They jump to the conclusion that I'm
> some ignorant moron. They also keep trying to sell Haskell as
> something dramatically, fundamentally -- nay transcendentally! --
> different from anything I've ever known.
>
> Are you doing that? Stop. Just stop. Haskell's big problem right now
> is adoption. And I'm telling you why adoption has been hard for me.
> You lecture back, telling me things I already know, making sweeping
> assumptions about me. When you do that, you're not part of the
> solution to Haskell's biggest problem right now. You're part of the
> problem.
>
> Regards,
> Michael Turner
> Executive Director
> Project Persephone
> 1-25-33 Takadanobaba
> Shinjuku-ku Tokyo 169-0075
> Mobile: +81 (90) 5203-8682
> turner at projectpersephone.org
>
> Understand - http://www.projectpersephone.org/
> Join - http://www.facebook.com/groups/ProjectPersephone/
> Donate - http://www.patreon.com/ProjectPersephone
> Volunteer - https://github.com/ProjectPersephone
>
> "Love does not consist in gazing at each other, but in looking outward
> together in the same direction." -- Antoine de Saint-Exupéry
>
> On Fri, Sep 17, 2021 at 4:19 AM <haskell-cafe-request at haskell.org> wrote:
> >
> > Send Haskell-Cafe mailing list submissions to
> > haskell-cafe at haskell.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > or, via email, send a message with subject or body 'help' to
> > haskell-cafe-request at haskell.org
> >
> > You can reach the person managing the list at
> > haskell-cafe-owner at haskell.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Haskell-Cafe digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: Haskell's "historical futurism" needs better writing, not
> > better tools (Richard Eisenberg)
> > 2. Re: Haskell's "historical futurism" needs better writing, not
> > better tools (Jeffrey Brown)
> > 3. Re: Haskell's "historical futurism" needs better writing, not
> > better tools (Gregory Guthrie)
> > 4. Re: Bundle patterns with type aliases (Carter Schonwald)
> > 5. Re: Bundle patterns with type aliases (David Feuer)
> > 6. Re: Bundle patterns with type aliases (David Feuer)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Thu, 16 Sep 2021 14:05:19 +0000
> > From: Richard Eisenberg <lists at richarde.dev>
> > To: Anthony Clayden <anthony.d.clayden at gmail.com>
> > Cc: haskell-cafe at haskell.org
> > Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs
> > better writing, not better tools
> > Message-ID:
> > <
> 010f017beeed148e-35512a1d-0412-45c5-b1ac-ca532fa70f72-000000 at us-east-2.amazonses.com
> >
> >
> > Content-Type: text/plain; charset="utf-8"
> >
> > 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.
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/08935eb4/attachment-0001.html
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Thu, 16 Sep 2021 09:34:09 -0500
> > From: Jeffrey Brown <jeffbrown.the at gmail.com>
> > To: Richard Eisenberg <lists at richarde.dev>
> > Cc: haskell-cafe <haskell-cafe at haskell.org>, Anthony Clayden
> > <anthony.d.clayden at gmail.com>
> > Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs
> > better writing, not better tools
> > Message-ID:
> > <CAEc4Ma0aNJuP8AMPvTRqyzQ=
> 0dJT_M_WQc9Kqb8JyvdPf9ncPw at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 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-0001.html
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Thu, 16 Sep 2021 15:28:16 +0000
> > From: Gregory Guthrie <guthrie at miu.edu>
> > To: Richard Eisenberg <lists at richarde.dev>, Anthony Clayden
> > <anthony.d.clayden at gmail.com>
> > Cc: "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
> > Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs
> > better writing, not better tools
> > Message-ID:
> > <
> DM6PR03MB4331EDE1A046D25E7209B90FA1DC9 at DM6PR03MB4331.namprd03.prod.outlook.com
> >
> >
> > Content-Type: text/plain; charset="utf-8"
> >
> > Educational research and learning theory shows that learning anything
> new is more effective and longer retained when it is connected to and
> builds on prior knowledge.
> >
> > People may understand anything new if presented as a completely new set
> of ideas or principles, but that knowledge is not persistent or long
> remembered.
> >
> > I personally find Haskell a good example of this. When teaching it one
> can show incrementally how it is the same in many ways as procedural
> programming languages. Then how it improves on them with first-class
> functions, currying, immutability, type abstractions, etc. These are all
> important ideas that they will also see in other IP languages, just much
> cleaner and more integrated in Haskell(!).
> >
> > Basic Haskell programs with these features can then be used as a bisis
> for both appreciating the language features and design and FP in general,
> and as a stepping stone to more advanced usages.
> >
> > Then introducing Functors, Monads, .... Are again an easy and well
> motivated step for improving on their existing IP experience, and show both
> nice abstractions and ideas, and a nice implementation and results.
> >
> > All of this connects to and builds on what they already know.
> >
> > Moving into all of the fancier type system features and pragmas, one
> enters into a realm where Haskell programs are no longer simple enough to
> easily read as they incorporate several levels of new abstractions and
> syntax.
> >
> > But at least students have a good basis for further exploration, and an
> appreciation of FP and Haskell. :-)
> >
> >
> >
> > From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of
> Richard Eisenberg
> > Sent: Thursday, September 16, 2021 10:05 AM
> > To: Anthony Clayden <anthony.d.clayden at gmail.com>
> > Cc: haskell-cafe at haskell.org
> > Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs better
> writing, not better tools
> >
> > 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<mailto: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.
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/cf601806/attachment-0001.html
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Thu, 16 Sep 2021 14:21:58 -0400
> > From: Carter Schonwald <carter.schonwald at gmail.com>
> > To: David Feuer <david.feuer at gmail.com>, GHC Users List
> > <glasgow-haskell-users at haskell.org>, ghc-devs <
> ghc-devs at haskell.org>
> > Cc: "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
> > Subject: Re: [Haskell-cafe] Bundle patterns with type aliases
> > Message-ID:
> > <CAHYVw0w33GC7mmaCY8k=74y0P8s4nbn_An6bZcj=
> SGbqiCznhw at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > These are great ideas! Could you please create a ghc tracker ticket with
> a
> > tiny examples or two?
> >
> > There may be specific technical reasons we might not be able to do so for
> > type synonyms in ghc, but I don’t see any obvious barriers in the case of
> > David’s excellent idea, I’ve def seen lots of great code out there where
> > you’d really want either associated pattern synonyms or to bundle pattern
> > synonyms with the exported public interface for a type class.
> >
> > I’m sure there’s some devil in the details but these sound lovely. Step
> -1
> > is making up 1-2 toy examples and explaining what and why you want it on
> a
> > ghc ticket!
> >
> > On Wed, Sep 8, 2021 at 1:25 PM David Feuer <david.feuer at gmail.com>
> wrote:
> >
> > > I would like that, along with the ability to bundle patterns with
> classes.
> > >
> > > On Wed, Sep 8, 2021, 1:13 PM Keith <keith.wygant at gmail.com> wrote:
> > >
> > >> Is there currently a way to 'bundle' a pattern with a type alias? And
> if
> > >> not, could that capability be added to the PatternSynonyms GHC
> extension?
> > >> (Is this the right place to ask, or should I be asking a GHC list?)
> > >>
> > >> --Keith
> > >> Sent from my phone with K-9 Mail.
> > >> _______________________________________________
> > >> 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.
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/ef761378/attachment-0001.html
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Thu, 16 Sep 2021 15:08:45 -0400
> > From: David Feuer <david.feuer at gmail.com>
> > To: Carter Schonwald <carter.schonwald at gmail.com>
> > Cc: "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>, GHC Users
> > List <glasgow-haskell-users at haskell.org>, ghc-devs
> > <ghc-devs at haskell.org>
> > Subject: Re: [Haskell-cafe] Bundle patterns with type aliases
> > Message-ID:
> > <CAMgWh9vSfQwQHkE3tg7d5NJ4CtAVLP2p=
> hsah3a5St3q0t7zeQ at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Here's an example:
> >
> > pattern State :: (s -> (a, s)) -> State s a
> > pattern State f <- (coerce . runStateT -> f) where
> > State = state
> >
> > This would be very nice to bundle with the State type synonym.
> >
> > On Thu, Sep 16, 2021, 2:22 PM Carter Schonwald <
> carter.schonwald at gmail.com>
> > wrote:
> >
> > > These are great ideas! Could you please create a ghc tracker ticket
> with a
> > > tiny examples or two?
> > >
> > > There may be specific technical reasons we might not be able to do so
> for
> > > type synonyms in ghc, but I don’t see any obvious barriers in the case
> of
> > > David’s excellent idea, I’ve def seen lots of great code out there
> where
> > > you’d really want either associated pattern synonyms or to bundle
> pattern
> > > synonyms with the exported public interface for a type class.
> > >
> > > I’m sure there’s some devil in the details but these sound lovely.
> Step
> > > -1 is making up 1-2 toy examples and explaining what and why you want
> it on
> > > a ghc ticket!
> > >
> > > On Wed, Sep 8, 2021 at 1:25 PM David Feuer <david.feuer at gmail.com>
> wrote:
> > >
> > >> I would like that, along with the ability to bundle patterns with
> classes.
> > >>
> > >> On Wed, Sep 8, 2021, 1:13 PM Keith <keith.wygant at gmail.com> wrote:
> > >>
> > >>> Is there currently a way to 'bundle' a pattern with a type alias?
> And if
> > >>> not, could that capability be added to the PatternSynonyms GHC
> extension?
> > >>> (Is this the right place to ask, or should I be asking a GHC list?)
> > >>>
> > >>> --Keith
> > >>> Sent from my phone with K-9 Mail.
> > >>> _______________________________________________
> > >>> 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.
> > >
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/82745d58/attachment-0001.html
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Thu, 16 Sep 2021 15:12:57 -0400
> > From: David Feuer <david.feuer at gmail.com>
> > To: Carter Schonwald <carter.schonwald at gmail.com>
> > Cc: "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>, GHC Users
> > List <glasgow-haskell-users at haskell.org>, ghc-devs
> > <ghc-devs at haskell.org>
> > Subject: Re: [Haskell-cafe] Bundle patterns with type aliases
> > Message-ID:
> > <CAMgWh9scvLkAeZpGV+FrLWReR55=
> gOBVLYBHOrwVDwbpY_G6rg at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Here's a class example:
> >
> > class (MFoldable t, Monoid t) => Sequence t where
> > singleton :: Elem t -> t
> > ....
> >
> > One might wish to write pattern synonyms for viewing the ends of a
> > sequence, like the ones in Data.Sequence, and bundle them with this
> class.
> >
> > On Thu, Sep 16, 2021, 2:22 PM Carter Schonwald <
> carter.schonwald at gmail.com>
> > wrote:
> >
> > > These are great ideas! Could you please create a ghc tracker ticket
> with a
> > > tiny examples or two?
> > >
> > > There may be specific technical reasons we might not be able to do so
> for
> > > type synonyms in ghc, but I don’t see any obvious barriers in the case
> of
> > > David’s excellent idea, I’ve def seen lots of great code out there
> where
> > > you’d really want either associated pattern synonyms or to bundle
> pattern
> > > synonyms with the exported public interface for a type class.
> > >
> > > I’m sure there’s some devil in the details but these sound lovely.
> Step
> > > -1 is making up 1-2 toy examples and explaining what and why you want
> it on
> > > a ghc ticket!
> > >
> > > On Wed, Sep 8, 2021 at 1:25 PM David Feuer <david.feuer at gmail.com>
> wrote:
> > >
> > >> I would like that, along with the ability to bundle patterns with
> classes.
> > >>
> > >> On Wed, Sep 8, 2021, 1:13 PM Keith <keith.wygant at gmail.com> wrote:
> > >>
> > >>> Is there currently a way to 'bundle' a pattern with a type alias?
> And if
> > >>> not, could that capability be added to the PatternSynonyms GHC
> extension?
> > >>> (Is this the right place to ask, or should I be asking a GHC list?)
> > >>>
> > >>> --Keith
> > >>> Sent from my phone with K-9 Mail.
> > >>> _______________________________________________
> > >>> 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.
> > >
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/1569e2b4/attachment.html
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
> >
> > ------------------------------
> >
> > End of Haskell-Cafe Digest, Vol 217, Issue 16
> > *********************************************
> _______________________________________________
> 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/20210917/4d0edf7f/attachment-0001.html>
More information about the Haskell-Cafe
mailing list