[Haskell-cafe] Interesting new user perspective
Andrew Coppin
andrewcoppin at btinternet.com
Fri Oct 10 17:35:05 EDT 2008
Steve Schafer wrote:
> On Fri, 10 Oct 2008 11:05:43 -0700, Jonathan Cast wrote:
>
>
>> No reason not to expose newcomers to Haskell to the thing it does best.
>>
>
> This is precisely why newcomers flounder. Yes, there certainly should be
> a "Haskell for experienced Java/C++ programmers : All of the advanced
> things you can do more easily than you ever thought possible." But
> that's not the way to attract Joe Programmer, who has never had to write
> a parser. Joe Programmer needs to be shown how Haskell can solve _his_
> problems. That might mean that you need to start with an extremely
> non-idiomatic Haskell program, one that has some of the "look and feel"
> of what programmers from other languages are comfortable with. And then
> transform that program, step-by-step, into something that takes
> advantage of Haskell's strengths.
>
Seconded.
On the one hand, "Haskell makes difficult things easy, and impossible
things possible". This is what's cool about the language. On the other
hand, an introductory text ought to start with something simpler and
_more familiar_ to get people used to the language first. Haskell is a
simple language, but there's an awful lot of new stuff to learn - new
language rules, and new techniques for structuring your code, and even
*thinking about* what code "is".
And another problem. I've written a few "intro to Haskell" documents
myself. These almost always end up degenerating into an exercise in
tripping over myself trying to explain everything all at once. Haskell
has a lot of very cool stuff in it. There are lots of things you need to
know to use it though. The "things" are all pretty simple, but they're
all so inter-related that it's difficult figuring out where to start.
Countless times I've written an example to demonstrate feature X, and
then realise "oh, wait, that requires features Y, Z, K, W, B, M and J
which I haven't mentioned yet..." It seems no matter how many
permutations you go through, you always end up with this problem. No
matter where you start with the language!
Maybe I need to sit down and draw a directed graph of related topics and
then perform a topological sort or something. ;-)
I sat down to read Real World Haskell today. The introduction was great
(although it seems to promise far too much). Chapter 1 is really solid.
But then Chapter 2... seemed to be a fairly unstructured tangle of
features and concepts all dumped on the reader at once. Like, "this is
how if/then/else works, oh, but that example program is recursive, so
this is how recursion works, oh, but that's lazy, so this is what thunks
are..." I can just imagine anybody reading all this going "wuh? Slow down!"
OTOH, it's easy to criticise what somebody else wrote. Much harder to
write something better yourself... :-/
PS. I'm curios to see what happens when the book gets to the
"interesting stuff". The intro seems to promise that Haskell has
libraries for all kinds of cool stuff - database access, sound, etc. But
IME it isn't true. I have tried and tried to make accessing a database
work from Haskell; the necessary libraries simply refuse to compile.
Ditto for sound. I yearn to do intricate DSP stuff in Haskell, but none
of the sound-related libraries will compile for me. (The libsdl binding
even comes with a specially-prepaired Windows package - which doesn't
work.) I want to see what the hell everybody else is doing differently
that makes this stuff actually work for them when it fails miserably for me!
More information about the Haskell-Cafe
mailing list