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

[Anthony Clayden]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210916/4089f456/attachment.html>