
Hi Manuel, 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, 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. Type inference (to my mind at least) fits the Python mindset very well. 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. 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. People on this list and others often say that the main body of the program is almost always imperative in style, but there's little demonstration of that fact - most examples are of a purely functional nature. Please understand I mean these comments in the most constructive sense. I have the highest respect for Haskell and the folks who work with it. Bryn
-----Original Message----- From: Manuel M. T. Chakravarty [SMTP:chak@cse.unsw.edu.au] Sent: Sunday, May 06, 2001 10:02 PM To: haskell-cafe@haskell.org Subject: Functional programming in Python
Two quite interesting articles about FP in Python are over at IBM developerWorks:
http://www-106.ibm.com/developerworks/library/l-prog.html http://www-106.ibm.com/developerworks/library/l-prog2.html
Two IMHO interesting things to note are the following:
* In Part 1, at the start, there is a bullet list of what the author regards as FP "features". I found the following interesting about this list:
- There is no mention of the emphasis placed on strong typing in many modern functional languages.
- The author makes it sound as if FP can't handle imperative features, whereas I would say that this is a problem of the past and wasn't an issue in many FP languages (Lisp, ML, ...) in the first place.
The opinion of the author is not really suprising, but I think, it indicates a problem in how FP presents itself to the rest of the world.
* In Part 2, the author writes at the end:
I have found it much easier to get a grasp of functional programming in the language Haskell than in Lisp/Scheme (even though the latter is probably more widely used, if only in Emacs). Other Python programmers might similarly have an easier time without quite so many parentheses and prefix (Polish) operators.
I think, this is interesting, because both Lisp and Python are dynammically typed. So, I would have expected the strong type system to be more of a hurdle than Lisp's syntax (or lack thereof).
Cheers, Manuel
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe