-----Original Message----- From: Manuel M. T. Chakravarty [SMTP:chak@cse.unsw.edu.au] Sent: Wednesday, May 09, 2001 12:57 AM To: brk@jenkon.com Cc: haskell-cafe@haskell.org Subject: RE: Functional programming in Python
[Bryn Keller] [snip]
and I have to agree with Dr. Mertz - I find Haskell much more palatable than Lisp or Scheme. Many (most?) Python programmers also have experience in more typeful languages (typically at least C, since that's how one writes Python extension modules) so perhaps that's not as surprising as it might seem.
Ok, but there are worlds between C's type system and Haskell's.[1]
[Bryn Keller] Absolutely! C's type system is not nearly so powerful or unobtrusive as Haskell's.
Type inference (to my mind at least) fits the Python mindset very well.
So, how about the following conjecture? Types essentially only articulate properties about a program that a good programmer would be aware of anyway and would strive to reinforce in a well-structured program. Such a programmer might not have many problems with a strongly typed language. [Bryn Keller] I would agree with this.
Now, to me, Python has this image of a well designed scripting language attracting the kind of programmer who strives for elegance and well-structured programs. Maybe that is a reason. [Bryn Keller] This, too. :-)
[Bryn Keller] [snip]
Absolutely. In fact, you have just pointed out one of the gripes that I have with most Haskell texts and courses. The shunning of I/O in textbooks is promoting the image of Haskell as a purely academic exercise. Something which is not necessary at all, I am teaching an introductory course with Haskell myself and did I/O in Week 5 out of 14 (these are students without any previous programming experience). Moreover, IIRC Paul Hudak's book http://haskell.org/soe/ also introduces I/O early.
In other words, I believe that this a problem with the presentation of Haskell and not with Haskell itself.
Cheers, Manuel
[1] You might wonder why I am pushing this point. It is just because the type system seems to be a hurdle for some people who try Haskell. I am curious to understand why it is a problem for some and not for others. [Bryn Keller] Since my first mesage and your and Simon Peyton-Jones' response, I've taken a little more time to work with Haskell, re-read Tackling the Awkward squad, and browsed the source for Simon Marlow's web server, and it's starting to feel more comfortable now. In the paper and in the server souce, there is certainly a fair amount of IO work happening, and it all looks fairly natural and intuitive.
Mostly I find when I try to write code following those examples (or so I think!), it turns out to be not so easy, and the real difficulty is that I can't even put my finger on why it's troublesome. I try many variations on a theme - some work, some fail, and often I can't see why. I should have kept all the versions of my program that failed for reasons I didn't understand, but unfortunately I didn't... The only concrete example of something that confuses me I can recall is the fact that this compiles: main = do allLines <- readLines; putStr $ unlines allLines where readLines = do eof <- isEOF if eof then return [] else do line <- getLine allLines <- readLines return (line : allLines) but this doesn't: main = do putStr $ unlines readLines where readLines = do eof <- isEOF if eof then return [] else do line <- getLine allLines <- readLines return (line : allLines) Evidently this is wrong, but my intuition is that <- simply binds a name to a value, and that: foo <- somefunc bar foo should be identical to: bar somefunc That was one difficulty. Another was trying to figure out what the $ sign was for. Finally I realized it was an alternative to parentheses, necessary due to the extremely high precedence of function application in Haskell. That high precedence is also disorienting, by the way. What's the rationale behind it? Struggling along, but starting to enjoy the aesthetics of Haskell, Bryn p.s. What data have your students' reactions given you about what is and is not difficult for beginners to grasp?