Functional programming in Python
Tue, 8 May 2001 09:53:07 -0700

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
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

> -----Original Message-----
> From:	Manuel M. T. Chakravarty []
> Sent:	Sunday, May 06, 2001 10:02 PM
> To:
> Subject:	Functional programming in Python
> Two quite interesting articles about FP in Python are over
> at IBM developerWorks:
> 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