Am Dienstag, 11. Dezember 2007 14:46 schrieb Hans van Thiel:
On Mon, 2007-12-10 at 20:00 +0100, Henning Thielemann wrote: [snip]
I raise my question once again: Must Haskell's tutorials be tailored to impatient programmers? Does Haskell need quick&dirty hackers?
IMO yes, because it exposes the language to the outside world and that's a form of testing. In the end, anything that's not usable is useless. Paraphrasing a quote about science in general, "There is nothing about Haskell that cannot be grasped by a second rate mind through persistence." Let's not exaggerate how difficult and special it all is. And the purpose of a tutorial is not to make the writer look smart and important, but to ease things for the reader. I wouldn't want to exclude the scurrilous unwashed from the Haskell experience, this close to Christmas, too. :-)
Regards,
Hans van Thiel
Maybe there are also patient people in the outside world so that we can still expose Haskell to the outside world while not trying to attract quick-and-dirty hackers. ;-) But who are those people? And what harm can they possibly do, assuming
On Tue, 2007-12-11 at 16:56 +0100, Wolfgang Jeltsch wrote: they fit the derogatory description?
Haskell is not a quick-and-dirty language but quite the opposite. Haskell’s unique selling propositions are features like type classes, higher order functions and lazy evaluation which make life easier in the long term. The downside of these features is that they might make life harder in the short term.
I don't know. In a sense Haskell is easier than, for example, C, because the concept of a function definition is more natural that that of assignments and loops. The idea that x = 5; x = x + 7 makes sense requires a complete new way of thinking. OK, once you've been doing it for a few years switching back to x = 5 + 7 is hard. I guess I do agree with you on lazy evaluation..
That said, I definitely think that we should make learning the language as easy as possible. But our ultimate goal should be to primarily show newcomers the Haskell way of problem solving, not how to emulate Python or Java programming in Haskell. Again, is there a danger of that happening?
Regards, Hans
Best wishes, Wolfgang