On Fri, 2008-10-10 at 22:43 +0100, Andrew Coppin wrote:
Jonathan Cast wrote:
Why would I want to do I/O, when I don't know how to do anything interesting with the input yet, or how to generate interesting output? I think the `I/O comes first' attitude is *precisely* the difference between mainstream programmers and Haskellers. The goal should be to create more Haskellers, not just more people whose code happens to be accepted by GHC.
So we need to teach these people not just about the syntax of the language, but the high-level game plan for how to use Haskell effectively. (Since it's SO different from normal languages.)
Right. I think what we're doing now *is* an effective program for doing this --- for programmers who are willing to learn --- and what y'all are proposing *isn't*. I think most programmers, looking at the first chapter of the tutorial you want, would be less inclined to learn Haskell than they are now. If they want to write ugly, unmaintainable code, they can always use C++ or Perl, after all. No need to learn Haskell for that.
Trouble is, as soon as you attempt to write a chapter like that, guess how many people are gonna actually read it? :-/
Presumably, everyone who knows Haskell now, and programs well in it, *has* read such a chapter.
I've got a Haskell book here (Hutton, 170 pages) that doesn't even mention how to open a file!
That short, and you expect minor features like that (that not every program even needs) to be squeezed in?
See, now it's things like that which stop more people attempting to learn Haskell. Most programmers would consider this an extremely basic and important thing to know, but Haskellers say "oh, THAT... it's not really important" and the newbies go "wuh? Which planet are you from? I'll go learn something less crazy, thanks."
It's a simple fact of programming, just one most developers don't know or don't think about. Pretending console or file I/O is somehow fundamental won't make GUIs start calling printf, or database clients start opening disk files. jcc