[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.


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