RE: Functional programming in Python
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
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
Interestingly enough, I have the same feeling with Python! 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.
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.
On Tue, 8 May 2001, Erik Meijer wrote:
Interestingly enough, I have the same feeling with Python!
Speaking of problems with Haskell, almost every time I write a larger program, I'm frustrated with lack of efficient arrays/hashtables in the standard. I know about ghc (I|U|M)Arrays for arrays and probably there are hashtables implemented in Edison library, but the program's portability would be lost and nhc/hugs would protest. I would be very happy if Haskell developers could settle on a simple, not sophisticated standard arrays. I personally would like an interface like: data Array type_of_objects_stored = ... -- abstract data MArray a b = ... -- abstract instance Monad (MArray a) put :: Int -> a -> Array a -> MArray () get :: Array a -> MArray a runMArray :: Int -> MArray a -> a -- int parameter is a size of used array. Even if they were put in IO, I still would not protest. Anything is better than nothing. Wojciech Moczydlowski, Jr
data Array type_of_objects_stored = ... -- abstract data MArray a b = ... -- abstract
put :: Int -> a -> Array a -> MArray a () Probably you meant:
On Fri, 11 May 2001, Wojciech Moczydlowski, Jr wrote: put :: Int -> a -> MArray a ()
get :: Array a -> MArray a a get :: Int -> MArray a a runMArray :: Int -> MArray a -> a -- int parameter is a size of used array. runMArray :: Int -> a -> MArray a b -> b [first a is an initializer]
Greetings Michal Gajda korek@icm.edu.pl
On Fri, 11 May 2001, Michal Gajda wrote:
On Fri, 11 May 2001, Wojciech Moczydlowski, Jr wrote:
Probably you meant: put :: Int -> a -> MArray a () get :: Int -> MArray a a runMArray :: Int -> a -> MArray a b -> b
You're of course right. I should have reread my letter before sending.
Michal Gajda
Wojciech Moczydlowski, Jr
participants (5)
-
brk＠jenkon.com -
Erik Meijer -
Manuel M. T. Chakravarty -
Michal Gajda -
Wojciech Moczydlowski, Jr