[Haskell-cafe] Haskell-Cafe Digest, Vol 217, Issue 22

[Michael Turner]

"I don't remember learning being as difficult as the claims on this
thread. (Memory can deceive, I guess.)"

Yes, it can. What really matters for that question is quantification.
How hard was it for other people a decade ago? How hard is it now?
What kinds of people were learning a decade ago? What kinds of people
are learning now? Without measures, you're just offering anecdotal
evidence.

You say that Haskell is having problems because it wasn't true to the
faith of "Avoid success at all costs". I always thought that was
supposed to be a wryly paradoxical statement of strategy, not an
"objective"; it was an impishly witty design-methodology heuristic,
not a hymn. Perhaps I'm misreading the community spirit at Haskell
Foundation, but it seems the tune shifted a while back.

You feel that the wrong kinds of people are learning Haskell now, that
it's "adopting" too many problem children. Thank you for your generous
offer to help me dig myself out of the hole you said I dug for myself,
though I can't understand why. After all, you've made it clear that
you think I'm a problem child. How else to explain why you distorted
what I've said elsewhere, in your summary of my positions, when you
could have just linked to my actual words, in archives, and let them
speak for themselves? "This juvenile delinquent has got Haskell all
wrong -- stop him before he vandalizes again!" But I suppose it's just
in your humanitarian nature to help even us juvenile delinquents.
Still, are you sure you don't have things upside down? I'm afraid I
can't offer much to you, from the way I feel the direction of gravity.
>From where I am, I think the only thing I can send downward to you is
a shovel full of dirt.

Is GHC part of the problem? I'm pretty sure of that. Are lots of
people getting Haskell wrong? That's symptomatic, at least. Has
Haskell gotten too big. I wouldn't be surprised. Should more
mathematical approaches be emphasized? I'm not against it, as long as
there's emphasis where it's due -- for some Haskellers coming up, it
may be better to bring in the math later, when they are already
feeling certain patterns in coding but don't quite know how they can
be concisely and rigorously expressed, and applied.

But over and above all that, you can't learn Haskell by sitting with a
reference manual, and trying things out in GHCI. Nor can you learn it
very easily by studying relatively mature code. And if "avoiding
success" means a book is giving examples that don't work anymore,
that's more frustration for readers who are already feeling the
steepness of the learning curve. People who want to learn need better
things to read.

What's "better"? It'll vary according to the reader. I'm a reader who
doesn't need another sermon about, say, the virtues of static types --
I converted to that religion long ago. I'm a reader who keeps the
machine level in mind, because I've been on projects where a new
release of a product that used to be fast enough is suddenly extremely
slow on startup initialization -- e.g., someone rewrote an SQL query
in the ORM to be "more elegant" but unfortunately also as if disk-head
seeks, platter rotations, and block reads were as virtually
instantaneous as, say, a line fetch from L3 cache.

The problem isn't overpopulation, it isn't like all those Irish that
Reverend Malthus thought should starve to death because, well, they'll
just breed out of control otherwise. It's the problem of
professionalization, which software has always had.

Entry is cheap and easy. Hardly a month goes by that we don't hear of
some (supposed) miracle of modern software science from some senior in
high school who started a software company. Turnover is high. This
means a lot of internal treadmills to retain knowledge of how the code
works. Lots of people burn out in ten years -- a ten years that, in
other engineering professions, is the point at which you're considered
fully seasoned, ready to hit your stride.

Why the continuing immaturity? Software hasn't killed a lot of people
(yet, he says, scanning the sky nervously for drones.) As long as most
software was mostly in corporate information systems, the casualties
tended to be only corporate-political. If you were such a casualty, it
was a bit like being a player in an MMPORG. You could get
"reincarnated" in another division, or another corporation, no matter
how ignominious your failure. Not much karmic justice either. Even if
you perpetrated fraud, which most financial firms prefer to cover up
than prosecute, sending you on, because it would be bad PR to send
your case to trial and have customers discover that the firm is not as
good about internal security threats as it claims.

To some extent, it's the very softness of software that has kept the
field so immature. Mistakes are made, but unlike a shifty bridge or a
shaky plane, they can be corrected cheaply and (for now) safely -- or
at least, any new bugs that your patch introduced are subtler, less
frequently manifested, easier to blame on someone else. Or maybe you
jumped to another company by the time your code became a problem.
Never have to grow up, not me!

But one sign of maturity in an engineering profession is that it stops
being a priesthood/guild and starts being a public responsibility. And
that starts with clear communication, within and beyond the
profession. Better tools are nice, of course. But if they are
effectively impenetrable to those outside the guild, you're not really
solving the problem. A firmer grounding in theory is also very
important. But if it's hermetic incantations and thumping of
mathematical bibles, that's also not good, clear communication, within
and beyond the profession.

Haskell has survived what is, for programming languages, a truly
staggering infant mortality rate. But what stage of life is it in,
now? Who are the models of maturity, for use of Haskell
professionally? How can they be elevated to influence, both within and
beyond Haskell programmer subculture? Bishops and guild masters were
ultimately answerable to feudal lords, and modern institutions that
fund software development are significantly feudal, both internally
and in their interactions with other institutions. Professionalism
confers an advantage: You can speak with the authority of backing from
your own institution, its own ethics and values, its own standards --
as long as that profession has proven that it's motivated from a sense
of public responsibility. But your profession has to speak clearly, as
clearly as possible, on all levels, to maintain itself as an
institution, to remain influential -- i.e., from a stance of being IN
these feudal mini-worlds but not OF them. This is because, in a way,
apart from the brains of its members, clear communication is the only
real asset a professional institution has. And that's where better
writing comes in.

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 Sat, Sep 18, 2021 at 12:40 PM <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: Numerics (was: Re: Trouble with asinh) (Jerzy Karczmarczuk)
>    2.  On finding the right exposition... (Viktor Dukhovni)
>    3. Re: On finding the right exposition... (Tom Ellis)
>    4. Re: On finding the right exposition... (Monads)
>       (Joachim Durchholz)
>    5. Re: On finding the right exposition... (Viktor Dukhovni)
>    6. Re: On finding the right exposition... (Monads) (Brandon Allbery)
>    7. Re: On finding the right exposition... (Monads) (Viktor Dukhovni)
>    8. Re: On finding the right exposition... (David Feuer)
>    9. Re: On finding the right exposition... (Tom Ellis)
>   10. Re: Numerics (was: Re: Trouble with asinh) (Barak A. Pearlmutter)
>   11. Re: On finding the right exposition... (Chris Smith)
>   12. Re: On finding the right exposition... (Albert Y. C. Lai)
>   13. Re: Haskell reference documentation,      laws first or laws last?
>       (Keith)
>   14. Re: Haskell's "historical futurism" needs better writing, not
>       better tools (Douglas McIlroy)
>   15. Better writing about Haskell through multi-metaphor       learning
>       (Michael Turner)
>   16. Re: Haskell-Cafe Digest, Vol 217, Issue 16 (Anthony Clayden)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 17 Sep 2021 20:31:24 +0200
> From: Jerzy Karczmarczuk <jerzy.karczmarczuk at unicaen.fr>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] Numerics (was: Re: Trouble with asinh)
> Message-ID: <32be9982-6be3-c136-c0b4-7622f3d88404 at unicaen.fr>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Le 17/09/2021 à 19:16, Carter Schonwald a écrit :
>
> > Hey Barak, is Common Lisp the only extant language to take those
> > issues seriously or are there other examples or better ones?
>
> // tan / atan troubles cited by Barak.
>
> Common Lisp??
>
> But even the ugly Python reacts better to such examples:
>
> *>>> from numpy import *
>  >>> rr, ii = 1.0e-20+0j, 1.0e-20j
> *
>
> *>>> tan(rr),arctan(rr)
> ((1e-20+0j), (1e-20+0j))
>  >>> tan(ii),arctan(ii)
> (1e-20j, 1e-20j)*
>
> *==*
>
> This works also with cmath (with arctan as atan).
> **
>
> Jerzy Karczmarczuk
>
>
>
>
> --
> L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210917/d32aa3d2/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 17 Sep 2021 15:47:19 -0400
> From: Viktor Dukhovni <ietf-dane at dukhovni.org>
> To: haskell-cafe at haskell.org
> Subject: [Haskell-cafe]  On finding the right exposition...
> Message-ID: <YUTwx+CTGxfVH/fy at straasha.imrryr.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Sep 17, 2021 at 05:02:09PM +0000, Richard Eisenberg wrote:
>
> > > Was it literally just a single sentence introducing a new word for a
> > > concept that made you "get it"?  Could you elaborate?  This is really
> > > quite remarkable.
> >
> > For me, coming from a mostly Java background (but with a healthy
> > dollop of functional programming thrown in the mix -- but no Haskell),
> > the phrase that unlocked monads was "programmable semicolon".
>
> No single exposition is optimal for all learners.  Some are
> visual-spacial, others verbal-sequential, and there are likely other
> learning styles I've not heard of.
>
> Therefore, even with good writing, some readers will have to work harder
> at understanding the material than others, because they have to
> translate the explanations into a form that works for them.
>
> Also some readers are learning programming and Haskell at the same time,
> while others are experienced programmers, but not in Haskell or another
> ML-family or functional language.
>
> A reader far removed from the target audience of the writer may find a
> well written document largely unhelpful.  There's no silver bullet.
>
> I haven't yet run into a "Haskell the language" book for experienced
> programmers that cuts to the chase and covers Haskell concisely a la
> K&R, focusing much more on the language than on how to write code (only
> as much code as it takes to minimally illustrate a language feature).
>
> Such a book would be challenging, because beyond writing basic numeric
> expresssions a large part of the language is needed all at once before
> one can write even some fairly simple functions.
>
> An off the cuff list of topics likely poorly ordered:
>
>     * Basic expressions
>         - Int, Word, Integer, Natural and Double
>         - Infix operators, associativity and precedence, parentheses
>         - Sections, (+), (.) and ($)
>         - let and where
>         - layout
>     * Program structure
>         - Function signature, head and body
>         - patterns and pattern bindings
>         - "case" and "if/then/else"
>         - guards and pattern guards
>         - modules, imports, and exports
>     * User defined types
>         - Algebraic data types, sums, products
>           + Tuples
>           + List (mention Array and Vector)
>           + String (and mention Text)
>           + Maybe
>           + Either
>         - Newtypes
>         - Type aliases
>         - GADTs
>         - Existential types
>     * More standard types
>         - Array (immutable)
>         - Vector (immutable)
>     * Lazy evaluation and strictness
>         - Space efficiency, seq and BangPatterns
>         - ByteString strict, lazy and builders
>         - Text strict, lazy and builders
>         - Strict fields and StrictData
>     * Type classes and constraints
>         - Integral
>         - Monoid
>         - Semigroup
>         - Foldable
>             + Strict and lazy folds
>     * Functors, Monads and Applicatives
>         - State and IO Monads
>         - map, fmap and ap
>         - File I/O
>         - Streaming
>         - Applicative option parsing?
>     * IO, ST and mutable values
>         - MVector
>         - MArray
>     ... lots more ...
>
> before long we have a book that's considerably larger than K&R.  This
> then leads to some frustration for the experienced programmer impatient
> to learn the basics of the language and get productive right away
> without relearning too much from the ground up.
>
> But then perhaps even modern C++ or Java has a rather non-trivial
> learning curve if one is starting from K&R C.
>
> There may not be a book that reasonably efficiently brings an
> experienced non-Haskell programmer to minimal proficiency, and
> the separation of pure functions from I/O means having to learn
> abstractions that don't come up in most other languages.
>
> For me, the journey was worth it, and the right book would surely have
> helped, (and would still help, I am far from the summit)  but in the end
> it still takes effort and time.
>
> --
>     Viktor.
>
> P.S.  Re: mental models of monads:
>
> Personally [verbal sequential], I find strained analogies unhelpful
> and distracting, so no desk clerks shuffling forms for me.
>
> I internalised Haskell monads, by implementing the Functor, Applicative
> and Monad instances for Reader and State a few times from scratch.  Once
> those were solid, ReaderT and StateT and their MonadTrans instances.
>
> Unsurpsingly, I have a mental model built around sequencing of internal
> state updates while passing data from one state to use in choosing the
> next state transition.
>
> I do appreciate "programmable semicolon", but only *after* getting a
> more concrete intituition for the standard examples.
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 17 Sep 2021 21:14:23 +0100
> From: Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] On finding the right exposition...
> Message-ID: <20210917201423.GK25255 at cloudinit-builder>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Sep 17, 2021 at 03:47:19PM -0400, Viktor Dukhovni wrote:
> > I haven't yet run into a "Haskell the language" book for experienced
> > programmers that cuts to the chase and covers Haskell concisely a la
> > K&R, focusing much more on the language than on how to write code (only
> > as much code as it takes to minimally illustrate a language feature).
>
> The Haskell Report is a good start.
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 17 Sep 2021 22:29:41 +0200
> From: Joachim Durchholz <jo at durchholz.org>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] On finding the right exposition...
>         (Monads)
> Message-ID: <e7074c0f-5fcf-e8c0-6905-a26a02f523b2 at durchholz.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Am 17.09.21 um 21:47 schrieb Viktor Dukhovni:
> > Personally [verbal sequential], I find strained analogies unhelpful
> > and distracting, so no desk clerks shuffling forms for me.
> >
> > I internalised Haskell monads, by implementing the Functor, Applicative
> > and Monad instances for Reader and State a few times from scratch.  Once
> > those were solid, ReaderT and StateT and their MonadTrans instances.
> >
> > Unsurpsingly, I have a mental model built around sequencing of internal
> > state updates while passing data from one state to use in choosing the
> > next state transition.
>
> I have been finding the Monad expositions misleading - that idea that
> monads are for sequencing or transitions or mutable state always felt
> wrong to me, since the monad laws don't talk about any of these things
> at all.
>
> And as far as I could understand the concept, monads are not about
> state, they're about "composing a linear sequence of functions". The
> functions' types need not be the same (that would degenerate into the
> concept of associativity), but the result type of one function must be
> the parameter type of the next.
> The monad can do whatever it likes with the functions - typically, wrap
> them in some other function and construct a function composition; there
> isn't much else you can do with them, though you're not doing much
> justice to the Maybe monad if you see it as a pipeline.
> Ah... right... and of course the pseudo associativity. I.e. it doesn't
> matter what parts of the total sequence you construct first.
>
> Of course, state transitions are a fine application of this concept.
> Or anything else where you see a function as a computation step and you
> want to run these steps in sequence.
> It's just that there are more kinds of monads.
> Except if you see Maybe as "do these operations in sequence until you
> hit the first that returns None, then abort". It depends on seeing
> functions as executable things though, and that's not really what
> Haskell is trying to be (or was trying to be 20 years ago, maybe
> everybody is now happy that Haskel finally can express imperative stuff
> via monads... no idea what people think)
>
> Regards,
> Jo
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 17 Sep 2021 16:39:15 -0400
> From: Viktor Dukhovni <ietf-dane at dukhovni.org>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] On finding the right exposition...
> Message-ID: <YUT889x9Mbtfsvg7 at straasha.imrryr.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Sep 17, 2021 at 09:14:23PM +0100, Tom Ellis wrote:
> > On Fri, Sep 17, 2021 at 03:47:19PM -0400, Viktor Dukhovni wrote:
> > > I haven't yet run into a "Haskell the language" book for experienced
> > > programmers that cuts to the chase and covers Haskell concisely a la
> > > K&R, focusing much more on the language than on how to write code (only
> > > as much code as it takes to minimally illustrate a language feature).
> >
> > The Haskell Report is a good start.
>
> I agree that the report is a useful reference, but it is a
> specification, not a book from which to learn the language.  I wouldn't
> actually suggest that anyone learn C by reading the C11 specication, or
> Haskell by working their way through the report.
>
> The report would of course be a useful source of topics and material for
> a Haskell the language book.
>
> --
>     Viktor.
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 17 Sep 2021 16:47:09 -0400
> From: Brandon Allbery <allbery.b at gmail.com>
> To: Joachim Durchholz <jo at durchholz.org>
> Cc: haskell-cafe <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] On finding the right exposition...
>         (Monads)
> Message-ID:
>         <CAKFCL4VoxQDEFAR3n3iiGOLhK=RbYgCBSHLR3GQep6pomJeyfg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I suspect a lot of people were pleased that they'd finally gotten rid of
> lazy Result -> Request.
>
> On Fri, Sep 17, 2021 at 4:34 PM Joachim Durchholz <jo at durchholz.org> wrote:
>
> > Am 17.09.21 um 21:47 schrieb Viktor Dukhovni:
> > > Personally [verbal sequential], I find strained analogies unhelpful
> > > and distracting, so no desk clerks shuffling forms for me.
> > >
> > > I internalised Haskell monads, by implementing the Functor, Applicative
> > > and Monad instances for Reader and State a few times from scratch.  Once
> > > those were solid, ReaderT and StateT and their MonadTrans instances.
> > >
> > > Unsurpsingly, I have a mental model built around sequencing of internal
> > > state updates while passing data from one state to use in choosing the
> > > next state transition.
> >
> > I have been finding the Monad expositions misleading - that idea that
> > monads are for sequencing or transitions or mutable state always felt
> > wrong to me, since the monad laws don't talk about any of these things
> > at all.
> >
> > And as far as I could understand the concept, monads are not about
> > state, they're about "composing a linear sequence of functions". The
> > functions' types need not be the same (that would degenerate into the
> > concept of associativity), but the result type of one function must be
> > the parameter type of the next.
> > The monad can do whatever it likes with the functions - typically, wrap
> > them in some other function and construct a function composition; there
> > isn't much else you can do with them, though you're not doing much
> > justice to the Maybe monad if you see it as a pipeline.
> > Ah... right... and of course the pseudo associativity. I.e. it doesn't
> > matter what parts of the total sequence you construct first.
> >
> > Of course, state transitions are a fine application of this concept.
> > Or anything else where you see a function as a computation step and you
> > want to run these steps in sequence.
> > It's just that there are more kinds of monads.
> > Except if you see Maybe as "do these operations in sequence until you
> > hit the first that returns None, then abort". It depends on seeing
> > functions as executable things though, and that's not really what
> > Haskell is trying to be (or was trying to be 20 years ago, maybe
> > everybody is now happy that Haskel finally can express imperative stuff
> > via monads... no idea what people think)
> >
> > 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.
>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210917/1034edbc/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 17 Sep 2021 16:50:25 -0400
> From: Viktor Dukhovni <ietf-dane at dukhovni.org>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] On finding the right exposition...
>         (Monads)
> Message-ID: <YUT/kfruttj2XJ96 at straasha.imrryr.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Sep 17, 2021 at 10:29:41PM +0200, Joachim Durchholz wrote:
>
> > > Unsurpsingly, I have a mental model built around sequencing of internal
> > > state updates while passing data from one state to use in choosing the
> > > next state transition.
> >
> > I have been finding the Monad expositions misleading - that idea that
> > monads are for sequencing or transitions or mutable state always felt
> > wrong to me, since the monad laws don't talk about any of these things
> > at all.
>
> That's the nature of mental models, they're first approximations with
> possible refinements.  Yes, there are monads for which State is a poor
> analogy.  The `Cont` monad comes to mind, one needs to "think different"
> when reasoning about `callCC`, `shift` and `reset`
>
> `State` as a mental model for monads captures basic sequencing with
> possible internal "effects" well enough to be a reasonable first
> approximation.  Already with List exploring all possible paths the
> fit is not ideal.
>
> --
>     Viktor.
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 17 Sep 2021 16:52:26 -0400
> From: David Feuer <david.feuer at gmail.com>
> To: "haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] On finding the right exposition...
> Message-ID:
>         <CAMgWh9uodbaLGcv=Jg_y00aK3urcLKTehDgOK0VxhqjMmkBcCg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> The Report is also a bit outdated in spots. Along with outdated library
> info, there's also a very old polymorphic recursion enhancement in GHC (and
> I believe also Hugs and other defunct implementations) that should've been
> added to Haskell 2010 but wasn't.
>
> On Fri, Sep 17, 2021, 4:42 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
> wrote:
>
> > On Fri, Sep 17, 2021 at 09:14:23PM +0100, Tom Ellis wrote:
> > > On Fri, Sep 17, 2021 at 03:47:19PM -0400, Viktor Dukhovni wrote:
> > > > I haven't yet run into a "Haskell the language" book for experienced
> > > > programmers that cuts to the chase and covers Haskell concisely a la
> > > > K&R, focusing much more on the language than on how to write code (only
> > > > as much code as it takes to minimally illustrate a language feature).
> > >
> > > The Haskell Report is a good start.
> >
> > I agree that the report is a useful reference, but it is a
> > specification, not a book from which to learn the language.  I wouldn't
> > actually suggest that anyone learn C by reading the C11 specication, or
> > Haskell by working their way through the report.
> >
> > The report would of course be a useful source of topics and material for
> > a Haskell the language book.
> >
> > --
> >     Viktor.
> > _______________________________________________
> > 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/83d583c3/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 17 Sep 2021 21:53:32 +0100
> From: Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] On finding the right exposition...
> Message-ID: <20210917205332.GL25255 at cloudinit-builder>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Sep 17, 2021 at 04:39:15PM -0400, Viktor Dukhovni wrote:
> > On Fri, Sep 17, 2021 at 09:14:23PM +0100, Tom Ellis wrote:
> > > On Fri, Sep 17, 2021 at 03:47:19PM -0400, Viktor Dukhovni wrote:
> > > > I haven't yet run into a "Haskell the language" book for experienced
> > > > programmers that cuts to the chase and covers Haskell concisely a la
> > > > K&R, focusing much more on the language than on how to write code (only
> > > > as much code as it takes to minimally illustrate a language feature).
> > >
> > > The Haskell Report is a good start.
> >
> > I agree that the report is a useful reference, but it is a
> > specification, not a book from which to learn the language.  I wouldn't
> > actually suggest that anyone learn C by reading the C11 specication, or
> > Haskell by working their way through the report.
>
> My memory of K&R may be deceiving me, but I seem to recall it is a lot
> closer to the Haskell Report than the C11 standard is.  I would be
> interested in the opinion of others who have read these documents more
> recently.
>
>
> ------------------------------
>
> Message: 10
> Date: Fri, 17 Sep 2021 21:54:13 +0100
> From: "Barak A. Pearlmutter" <barak at pearlmutter.net>
> To: Carter Schonwald <carter.schonwald at gmail.com>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] Numerics (was: Re: Trouble with asinh)
> Message-ID:
>         <CANa01BJq=7EzKXV26N-fXP3ptNzE5oDXOoa22fbf2ZZov8cYpA at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I suspect that most implementations of Common Lisp just call the C
> standard library catan(3) etc, which are well tuned.
>
> $ clisp
> Welcome to GNU CLISP 2.49.92 (2018-02-18) <http://clisp.org/>
> [1]> (atan #c(0 1d-40))
> #C(0 1.0d-40)
>
> In this particular case, the problem is that the Haskell Data.Complex
> code has its own implementation of atan, which uses a log(1 + x) in
> calculating the imaginary part. A foreign function call to the
> appropriate libm routine would robustly address this, but that would
> be difficult because it's trying to be generic over RealFloat a =>
> Complex a, instead of special casing Complex Float / Complex Double.
> Anyway, the Standard Prelude code for this is naïve: it should call
> log1p, at the very least—which it actually goes to the trouble of
> defining correctly, but not exporting.
>
>
> ------------------------------
>
> Message: 11
> Date: Fri, 17 Sep 2021 16:59:09 -0400
> From: Chris Smith <cdsmith at gmail.com>
> To: haskell-cafe <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] On finding the right exposition...
> Message-ID:
>         <CAPq5PvKmVZkZyEfunjDOWa=wp6t9U4jRs0X6Dh4oshapD_QADA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, Sep 17, 2021 at 3:52 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
> wrote:
>
> > No single exposition is optimal for all learners.  Some are
> > visual-spacial, others verbal-sequential, and there are likely other
> > learning styles I've not heard of.
> >
>
> If you'll forgive the slight argumentativeness, I do want to point out, as
> someone who follows education research quite a bit, that this learning
> styles hypothesis is a pretty well-known myth.  It sounds good and feels
> true, but has been falsified every time someone has tried to gather
> evidence to validate it.
>
> There are some related statements that are true.  For example, different
> people certainly have different preferences for modes of presentation, but
> those preferences don't actually correlate with how well they learn.
> Feeling confused or unsatisfied doesn't mean you're not learning!  For
> another example, people definitely do learn better when they see
> information from several different points of view, but it's apparently not
> because different people learn best from different points of view, but
> rather because all people learn best when they have more different
> perspectives to integrate.  And for a last example, people definitely do
> have preferences and abilities for learning different kinds of content,
> which are in turn most naturally communicated in certain ways, but it's
> apparently the natural way to present an idea that matters more in terms of
> learning, not the individual's preferences for style.
>
> This is actually pretty related to what we're talking about here.  If it
> were true that different people understand monads better when they are
> presented in ways that match the individual's style of learning, reliable
> evidence of this would be revolutionary in education research.  (Meaning:
> it's very, very likely not to be true, though I cannot point to research
> that studies understanding monads, in particular.)  But luckily, the
> solution to this myth is just *not* to differentiate, but rather to provide
> all of these points of view to everyone who is learning, whether they
> *feel* that
> this is the right presentation or it *feels* like it's making sense to them
> or not.  When evaluating our own learning experiences, we should be careful
> to remember that the times we were learning were probably actually the
> times we felt a bit confused.  The presentation that finally made sense
> probably wasn't the most helpful one.
>
> See https://www.google.com/search?q=learning+styles+myth for lots of
> sources.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210917/82c956a5/attachment-0001.html>
>
> ------------------------------
>
> Message: 12
> Date: Fri, 17 Sep 2021 17:02:23 -0400
> From: "Albert Y. C. Lai" <trebla at vex.net>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] On finding the right exposition...
> Message-ID: <cfad7803-0717-3d1d-8717-2d7b6bd367b3 at vex.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I agree with improving teaching/learning materials. But here is a small
> point I object to:
>
> On 2021-09-17 3:47 p.m., Viktor Dukhovni wrote:
> > On Fri, Sep 17, 2021 at 05:02:09PM +0000, Richard Eisenberg wrote:
> >
> > No single exposition is optimal for all learners.  Some are
> > visual-spacial, others verbal-sequential, and there are likely other
> > learning styles I've not heard of.
>
> Please consult for example https://www.youtube.com/watch?v=rhgwIhB58PA
>
> It is long past high time to kill that outdated zombie myth.
>
> What I stand behind is: Every student needs every perspective they can
> get their hands on.
>
> But it is not because every student is only good at just one thing.
>
>
> ------------------------------
>
> Message: 13
> Date: Fri, 17 Sep 2021 21:04:27 +0000
> From: Keith <keith.wygant at gmail.com>
> To: Haskell Cafe <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] Haskell reference documentation,    laws
>         first or laws last?
> Message-ID: <7E95F060-6A82-4F5C-94D8-B21458C672BF at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Perhaps it would make sense to have a 'using the class' section and a 'writing instances' section.
> The first would focus on more concrete and intuitive examples.
> The second would explain how and why to follow the laws, maybe with specific ways to avoid pitfalls and extra work (e.g. when you can and can't DeriveFoldable, when to use `foldMapDefault` when to define only `foldr` or `foldMap` or to use `toList` to define others.
>
> It's super important that folks gan define legal instances so things don't brow up in their faces (e.g. an Applicative instance that zips but defines `pure` as a singleton). But often all they need to know is `DeriveTraversable` exists and works as long as you don't define things in strange ways (like conceptually reversed lists).
> --Keith
> Sent from my phone with K-9 Mail.
>
> On 17 September 2021 08:30:37 UTC, Ignat Insarov <kindaro at gmail.com> wrote:
> >Hello Viktor.
> >
> >Thank you for your continuous effort.
> >
> >I have been writing Haskell for years now and even getting paid for
> >it. I care nothing for the laws — I rarely apply equational reasoning.
> >I am a visual person, to me intuitive grasp is the tool of choice. I
> >also know a few newcomers to Haskell and I am certain they make zero
> >use of the laws.
> >
> >My thus informed view is that laws are fine in the end and useless at the start.
> >
> >On Fri, 17 Sept 2021 at 04:48, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> >>
> >> On Thu, Sep 16, 2021 at 06:51:42PM -0400, David Feuer wrote:
> >>
> >> > The last time I went to look at the laws it took me a couple minutes to
> >> > find them. I use them to write instances. Pretty important, IMO.
> >>
> >> I agree the laws are important to document, I just don't think they
> >> belong at the top of the module.  The beginner to intermediate users
> >> will be using the library and existing instances for some time before
> >> they start to write their own instances.
> >>
> >> If more modules adopt something like the style of the new Data.Foldable,
> >> experienced users will know to look for the laws at the end, if not
> >> still present at the top of the module.
> >>
> >> Of course perhaps the community would prefer the original Laws first
> >> format, I'm fine with that emerging as the consensus.  Perhaps worthy
> >> of a separate thread (made it so).
> >>
> >> Of course the conjectured users who might most benefit from not being
> >> intimidated by being exposed to laws before they're ready to understand
> >> them might not be present on this forum...
> >>
> >> --
> >>     Viktor.
> >> _______________________________________________
> >> 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/20210917/34bcb5fe/attachment-0001.html>
>
> ------------------------------
>
> Message: 14
> Date: Fri, 17 Sep 2021 21:47:34 -0400
> From: Douglas McIlroy <douglas.mcilroy at dartmouth.edu>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs
>         better writing, not better tools
> Message-ID:
>         <CAKH6PiUxxA16=2Q9SyJU0Mk=YRfZUaT8O18DNUbOW_+S3p38yg at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> > 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.
>
> There's a category error (in the sense of logic, not algebra) here.
> Learning a language is not comparable to understanding a program.
> The concept of lambda calculus is far more subtle than that of
> Turing machine. But if you know both, a program is likely to be
> much easier to understand when presented in lambda calculus
> than when presented as a Turing machine.
>
> Doug
>
>
> ------------------------------
>
> Message: 15
> Date: Sat, 18 Sep 2021 11:56:37 +0900
> From: Michael Turner <michael.eugene.turner at gmail.com>
> To: haskell-cafe at haskell.org
> Subject: [Haskell-cafe] Better writing about Haskell through
>         multi-metaphor  learning
> Message-ID:
>         <CANHeBij8chjV_K3w0Dnt5T7R4vPMvSusHOLgMG64qRrRkMb-xQ at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Well, this is certainly blowing up into something bigger than I
> thought it would. (At one point last night, 12 people had my "Haskell
> in Plain English" essay/chapter open on Google Docs, a very
> unintentional side effect.)
>
> Me: "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."
>
> A response:  "Was it literally just a single sentence introducing a
> new word for a concept that made you "get it"?  Could you elaborate?
> This is really quite remarkable."
>
> Richard Eisenberg: "For me, coming from a mostly Java background (but
> with a healthy dollop of functional programming thrown in the mix --
> but no Haskell), the phrase that unlocked monads was "programmable
> semicolon"."
>
> I think one explanation for the Monad Tutorial Explosion (and how it
> still didn't work for a lot of people) is that there's no single right
> metaphor that will finally make monads "click". It depends on what
> combination of conceptions (and perhaps all misconceptions to be
> dispelled) is floating around in given mind. And minds vary.
>
> Workflow is a metaphor at one useful level. "Programmable semicolon"
> is a metaphor at another useful level.
>
> Semicolon as imperative-language separator actually hides a lot that's
> going on in a real CPU. Even if the imperative language is assembly
> language, the compiled instructions go to an instruction fetch/decode
> unit that -- these days especially -- can be engaged in a bewildering
> number of tasks, including finishing up several previous instructions,
> translating the decoded instruction to what amounts to microcode that
> get sent to an instruction cache, and fetching the next few
> instructions even as it's been decoding the instruction fetched into a
> little to-do list for the CPU. Perhaps we can think of instruction
> fetch/decode as "monadal" -- it's wildly (but not chaotically) mapping
> a previous state of the machine into new one. After all, it's all
> still Turing machines down there somewhere (but even the Turing
> machine was mathematically defined as a function that maps one
> tape-state to the next while it's also mapping its internal state to a
> new state.) So the semicolon can be thought of as lexically exposing
> the fetch-decode operator in the CPU's own little program.
>
> The "workflow" metaphor is at a higher level. If you think of how
> incoming data can be sorted and parceled out as if to a number of
> desks in an office, with forms processed at a desk going from one
> outbox to another desk's inbox, you're ignoring exact sequencing. It's
> the view where you're labeling desks by their specialized tasks and
> drawing outbox-inbox connections. In this view, it matters little
> that, in the one-instruction-at-a-time CPU model, there's only one
> "clerk" who (ridiculously, I know) puts a form in an inbox, then takes
> it out again, puts it in the inbox of another desk, then sits down at
> that other desk, takes the same form out and does the very specific
> form-processing task assigned to that desk. You can instead imagine it
> as some sluggish bureaucracy where everyone else but the single busy
> clerk is waiting for a form to hit their empty inboxes. The fact is,
> "one-instruction-at-a-time CPUs" hardly exist anymore except in the
> cheapest microcontrollers -- there are all multitasking like crazy.
> And this is because CPU designers work very hard to see how much of
> the little bureaucracy they can actually keep busy, ideally at all
> times, but at least at high throughput for average instruction
> streams, even if 100% utilization is seldom reached. (Lambda, the
> Ultimate Semicolon?)
>
> Bryan: "Listing sequential actions one after the other is so intuitive
> you see it everywhere. Take baking recipes as one example. Or assembly
> code. Or poems."
>
> Yes, sequencing just grows out of the fact of time. You'd think that
> poems aren't really sequences of tasks to do. But in a way, they are,
> and in a sense that matters for my attempts at natural-language
> understanding. There IS an implicit imperative in the energy required
> to speak: the subtext of any statement addressed to another person
> (even when it's dead poet to living reader) is: think about what I'm
> saying. Each new word in a sentence being spoken maps the listener's
> mind-state to a new one. The purpose of the sequencing is to build up
> state in the listener's mind.
>
> "When a Haskeller says, "Monads are great! They let you chain effectful
> actions together!" it can take a very long time to understand they actually
> mean exactly what they're saying — the usual intuition is that sequencing
> actions can't possibly be a real problem, so you go round and round in
> circles trying to understand what "effectful" means, what "action" means,
> and how these oh-so-important "laws" have anything to do with it."
>
> Yes, it's sort of like aliens from outer space with a very alien
> consciousness, and a different relation to the dimension of time, and
> they are exulting (to each other, and to themselves, really, more than
> to you):
>
> "Periods at the ends of sentences are great! They enable these strange
> blobs of protoplasm who call themselves 'human' to more easily map the
> states of these internal things they call 'neurons' into new states.
> No wonder we've been having such trouble trying to tell them what to
> do, using our intuitively obvious gestaltic visual patterns that allow
> us to grasp, with our quantum-computer brains, a whole meaning at
> once, through our retinas."
>
> (Yes, I am riffing a little here on the SF movie Arrival.)
>
> Math is this world where we can feel a little like that. Instead of
> thinking of a function as a machine that takes inputs, grinds away for
> a little while, and extrudes outputs, you can think of all inputs and
> output as already existing, and reason logically from the resulting
> properties. Haskell's laziness helps you fake what you can't really
> have: infinite workspace and the ability to do everything in an
> instant. It's a fake-it-til-you-make-it language, and you don't have
> to be Buzz Lightyear going to infinity and beyond, perhaps to all the
> way to the galaxy Aleph-omega. You just have to make a Haskell program
> do something that people like as much as their Buzz Lightyear doll.
>
> The math view is a useful view at one level, but it can only help you
> so much. I greatly enjoyed the level where I could define a Turing
> machine as a mapper from one infinite tape to another, then imagine
> all possible Turing machines as a countably infinite set. I could then
> prove, with Cantor diagonalization (abstractly, at least, though not
> very intuitively) that there are things Turing machines can't do. I
> loved that.
>
> But I also listened to grad students mutter about how recursive
> function theory may be beautiful and all, but it's now classical, and
> therefore dead for their own practical purposes (getting a PhD,
> getting onto tenure track.) And by then I knew I wasn't good enough at
> math to make a go of computing theory in their world, as a career, no
> matter what. I think Simon Peyton-Jones had a similar experience of
> academia -- he wasn't a John Hughes -- but he found a way through
> anyway.
>
> Bryan: "I can understand why that [puzzled newbie] viewpoint might be
> long-forgotten by those who were involved in the effort to solve it.
> :) And I appreciate that it was solved in such a general way that it
> can be applied to so many seemingly unrelated things! That's the
> beauty of mathematics!"
>
> Yes, it's there. But in user experience design (and writings about
> Haskell ARE part of its user experience) there's a saying: the
> intuitive is the familiar. At some point in gaining sophistication,
> it's no longer intuitively obvious to you why something wasn't
> intuitively obvious for you before. You're so absorbed in where you
> are that you don't remember quite how you got there. You might even
> assume that everyone who has gotten where you are has gotten there by
> the same route. And, if you can dimly remember how you got a flash of
> inspiration, you might end up writing yet another monad tutorial that
> few people understand.
>
> "Workflow" helped me. And now "programmable semicolon" is helping a
> little, in another way.
>
> I presented a strategy at the NSMCon-2021 conference: think of NSM
> reductive paraphrasing as writing very complete and precise code for
> natural-language terms and grammar rules, using NSM primes and syntax
> as a kind of logic programming language -- one that might even be very
> simply translatable to Prolog.
>
> I did some coding experiments and saw a problem: viewed more
> procedurally -- i.e., with each line of an NSM explication adding to a
> conceptual schema of a natural-language meaning -- NSM wasn't
> single-assignment. A Prolog interpreter couldn't just try a match,
> looking at each statement of an explication in relative isolation, and
> bail out when a statement failed to be true in the given context of
> the attempted match. It had to drag some state along just to resolve
> what the NSM prime "this" referred to. (Think of "it" in GHCI.)
>
> OK: effects. But wait, more: scoped effects. You want to strip some
> schema-stuff back out if a match failed midway through, then try
> another match somewhere else. OK: I need a context stack to store
> assertions that succeeded. Uh-oh, Prolog doesn't give me that paper
> trail. Dang. And I still want the one-for-one translation of sentences
> in an NSM reductive paraphrase to something like Prolog.
>
> OK: I need to grab control of sequencing, so that I can not only use
> the intrinsic Horn clause resolution without pain. But I also want it
> to hold onto the assertions that succeeded, and knit them into the
> growing conceptual schema that's part of the state. AND I want it roll
> those back out, transactionally, if a match didn't succeed. It turns
> out that Prolog makes this not too much harder than, say, a Lisp with
> transactional memory.
>
> So: I think I might now return to my Prolog code and see if I was
> unconsciously reinventing some kind of monad. Because because I felt
> forced by Prolog's limits to write my own semicolon. It wasn't too
> hard, though the resulting code required for NSM explications looks
> clunkier now. (Prolog is very limited in syntax extensibility.) Maybe
> there's some way in which Haskell makes it easier still, and
> nicer-looking too.
>
> None of which is to say that "programmable semicolon" will immediately
> help everyone pick the conceptual lock of monads. But for those who
> just bonk on "programmable semicolon", it might help to point out that
> the load-operate-store model of CPUs is a lie these days. Say a little
> about why it's not true. Then again pose semicolon as a kind of
> operator. People like to think, "OK, this statement will finish, and
> the one after the semicolon will start." It's a convenient view, even
> though in fact, while the imperative statement is in progress, the CPU
> might have already fetched instructions beyond it, and scheduled them
> for speculative execution.
>
> Or, you can tell them, "Just learn lambda calculus, then study monads
> algebraically, and here's a side dish of category theory while I'm it.
> Bon appetit." How's that working for you, guys? It doesn't work for
> me. And I don't think it's because I can't do the math. It's that I
> often write code to see whether I'm thinking about a problem the right
> way.
>
> And is that so bad? I believe it was in Stewart Brand's "II Cybernetic
> Frontiers" where a researcher at Xerox PARC, Steve ("Slug") Russell,
> one of their star hackers, was described by his peers as "thinking
> with his fingertips."
>
> I'm no star hacker, but "workflow" feels like it will make my
> fingertips smarter. "Programmable semicolon" feels like it will make
> my fingertips smarter. You think top-down mathematically? Well, bon
> appetit. It's not to my taste. No single way is likely to work for
> all. Math is not some fundamental reality. It's not even reality -- in
> fact, it gains a lot of its power precisely from being imaginary. And
> it's just a bunch of metaphors too.
>
> 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
>
>
> ------------------------------
>
> Message: 16
> Date: Sat, 18 Sep 2021 15:35:29 +1200
> From: Anthony Clayden <anthony.d.clayden at gmail.com>
> To: haskell-cafe at haskell.org
> Subject: Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 217, Issue 16
> Message-ID:
>         <CABU_mxgz7gYycU6BEL0=xU4E=Q7KxRZ-T7C26n1sTJODwkoGtQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> >>* Haskell's big problem right now is adoption.
> *
>
> Heh heh, this sentence is multi-ways ambiguous. As in the 'problem' is
> that there's too many adopters/the wrong sort of people trying to
> adopt Haskell. The 'problem' is that Haskell is not keeping to its
> objective to "avoid success at all costs".
>
> > 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.
>
>
> Thank you for saying that out loud. I've been feeling for some time
> that GHC is getting harder to use. You're telling me that because I
> don't get Category Theory you want to throw me out of using Haskell.
> People who are allergic to Lambda-calculus are already excluded.
>
> So the ostensible difficulty on these threads: that the documentation
> is unhelpful, is not the problem at all. In fact it's deliberate that
> the docos are exclusionary. As part of this grand plan, Viktor is
> deliberately making the Libraries docos impenetrable. (By which I
> mean: the style is clear, but the material is unlearnable. Apparently
> I need to know what is an endomorphism before I can write a Foldable
> instance)
>
> And that explains a paradox: I learnt Haskell over a decade ago. There
> was far less intro material; and certainly no store of StackOverflow
> questions/answers. It should have been more difficult to learn than
> today. But I don't remember learning being as difficult as the claims
> on this thread. (Memory can deceive, I guess.)
>
> Back then Haskell was a much smaller, simpler language. There was less
> that could go wrong at the type level; and the error messages didn't
> keep recommending to switch on bamboozling features that (as it turned
> out) made the difficulty harder. Don't go claiming that if I switch
> off those features today it's as if I was still using H2010. Simply
> not true.
>
> I know that's not true, because I can still go back and use Hugs, or
> use GHC v7.10 (vintage ~2015), and have a much more pleasant/less
> bamboozling experience.
>
>
> Then "Haskell's big problem right now" is (depending on your point of
> view) either GHC or too many of the wrong adopters. And with Dependent
> Types coming along GHC is going to get a lot worse. (Maybe GHC will
> eventually get through the fog, throw out a load of cruft and become
> on average as usable as v7.10. I'm not prepared to go through the pain
> for 5 years to find out. I'll stick with v7.10.)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210918/144e99fc/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 22
> *********************************************