On Wednesday 21 December 2005 18:48, Udo Stenzel wrote:
Donn Cave wrote:
Meanwhile, that fellow evidently didn't write any compiler in Haskell at all. Better a C++ program than a Haskell program that offends you?
Oh no, he actually wrote something disgusting built mostly out of regexes in Perl. I don't think it even works, and I don't think I could have convinced him to Do The Right Thing in whatever language.
But that's besides the point. The conviction that a parser or lexer or prettyprinter means IO is simply wrong, and imho a tutorial should show how much is purely functionally possible before introducing control flow, mutable variables and all the other ugliness. It's more productive this way.
This is a red herring IMO. A good tutorial on Haskell can mention and explain how to do IO in the first chapter and /still/ show clearly and convincing how to do most of the real work in an elegant, purely functional style. It could even contain a 'bad example' where IO is used unnecessarily and compare it to the 'good' functional version. It is not a good idea to treat beginner's in Haskell as little children who must be protected from the bad world of IO as long as possible. (FWIW, it can be argued that this isn't even a good attitude toward little children.) Especially since most Haskell newcomers will have a background in imperative programming, as someone esle already mentioned. Of course, /precise/ explanation of the IO monad must be postponed to a later chapter, and surely only /after/ introducing monads in general and giving some non-IO examples. I would also argue that the word 'category theory' should /not/ appear in the main text of a tutorial (a small footnote might be acceptable, as well as a reference in a late chapter named 'further reading'). Ben