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!