Functional programming in Python
Manuel M. T. Chakravarty
Wed, 09 May 2001 17:56:39 +1000
> 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.
Ok, but there are worlds between C's type system and
> Type inference (to my mind at least) fits the Python mindset very
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.
 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.