brk@jenkon.com wrote,
It's interesting to me to note the things that were interesting to you. :-) I'm the author of the Xoltar Toolkit (including functional.py) mentioned in those articles
Cool :-)
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]
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. 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.
I think most Python programmers would be glad to have strong typing, so long as they don't have to press more keys to get it. If you have to declare all your types up front, it just means more time spent changing type declarations as the design evolves, but if the compiler can just ensure your usage is consistent, that's hard to argue with.
Type inference (as opposed to mere type checking) is certainly a design goal in Haskell.
As for the difficulty with imperative constructs, I agree it's not even an issue for many (Dylan, ML, et. al.) languages, but for Haskell it still is, in my humble opinion. I found the task of writing a simple program that did a few simple imperative things inordinately difficult. I know about the 'do' construct, and I understand the difference between >> and >>=. I've read a book on Haskell, and implemented functional programming support for Python, but trying to use Haskell to write complete programs still ties my brain in knots. I see there are people writing complete, non-trivial programs in Haskell, but I don't see how.
To be sure, I owe Haskell more of my time and I owe it to myself to overcome this difficulty, but I don't think it's only my difficulty. In the Haskell book I have, discussion of I/O is delayed until chapter 18, if memory serves. One thing that might really help Haskell become more popular is more documentation which presents I/O in chapter 2 or 3. Clearly the interesting part of a functional language is the beauty of stringing together all these functions into a single, elegant expression, but an introductory text would do well to focus on more immediate problems first.
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.