Good introduction to functional programming with Python?

[Tim Peters]

[Alex Martelli]
> We agree on far too much, and dwelling on agreements ain't no
> fun, so, let's pick on a difference:

Well, if we're still addressing the original fellow's question about a good
intro to FP, I think "Haskell or Scheme, depending" is as good an answer as
he's ever going to get -- so there's no real *need* to disagree beyond that
<wink>.

[Tim]
>> ... then if FP is "about" anything, it's about the art of using
>> higher-order functions, and I believe mere mortals *need* a
>> strong static typing system to keep those straight.  Maps returning
>> maps returning maps ... can get hard to follow real fast.

[Alex]
> Erlang designers and practitioners seem to disagree: and Erlang
> is arguably the FP around which most $$$ turn in today's real-
> world, what with its use in Ericsson and Bluetail's acquisition by
> a Nortel subsidiary.  I have no real experience with it, and thus
> no solid basis on which to judge it, but, sordid materialist that
> I am, I _am_ impressed when hundreds of megabucks are in play:-).
> And Erlang relies on strong dynamic (aka latent)  typing, and an
> emphasis on concurrency in an FP setting, to (allegedly) reach good
> levels of reliability, performance, ease of learning, programmer
> productivity.
>
> Static typing has its place, but so, it appears, does latent
> typing, even in FP.

I haven't used Erlang at all, so that makes it an excellent battlefield:  no
unpleasant haggling over facts <wink>.  I'll hazard a guess based on the
Erlang FAQ (http://www.erlang.org/faq/t1.html).  According to 10.9.1,

    10.9.1. Erlang should have a static type checker

    Erlang has a type checker.  Several man years of work have been
    put into the type checker by people who "should know" (Joe
    Armstrong, Phil Wadler, Simon Marlow, Thomas Arts) but the result
    is still not a "must use" part of the language.  The type checker
    is not widely used.

So they have a capable static type inference system but nobody cares,
neither the implementers nor the users.  There are two reasons for that I'm
guessing:

1. Erlang appears to be a nice implementation of a generalization of CSP,
and of a microthread flavor.  They have a crushing speed advantage over most
OS-level threads in their niche ("Context switching between Erlang processes
is typically one or two orders of magnitude cheaper than switching between
threads in a C program"), so don't care whether anything else "runs really
fast":

    1.4. What sort of problems is Erlang not particularly
    suitable for?

    Anything where constant-factors are crucial for performance,
    such as image processing, signal processing, sorting large
    volumes of data, device drivers and low-level protocol termination.

    Most (all?) large systems developed using Erlang make heavy use
    of C for low-level code, leaving Erlang to manage the parts
    which tend to be complex in other languages, like controlling
    systems spread across several machines and implementing complex
    protocol logic.

2. While the "complex protocol logic" may be complex indeed, protocols
typically sling a small number of very simple data types (like "Data is
passed as a sequence of bytes between the Erlang processes and the external
UNIX processes") in very rigid ways.  In fact, I got so suspicions at the
lack of *any* higher-order functions in any of the examples I saw, I
downloaded the Erlang book and read this ("Concurrent programming in
Erlang", ISBN 0-13-508301-X):

    Currying, higher-order functions, lazy evaluation, ZF
    comprehension, logical variables, deep guards, etc., add to
    the expressive power of a declarative programming language, but
    their absence is not a sign cant detriment to the programming of
    typical industrial control applications.

In the absence of higher-order functions, I can believe programmers don't
have much trouble reasoning about types without declarations.  They don't
use the static type checker because it's more trouble than it's worth!

Fine by me.  I must say, though, that Erlang appears to occupy an extreme
corner of the FP universe.

    9.2 Why can't I change the value of a variable?

    ... [because you can't <0.5 wink>] ...

    (This behaviour is called "single assignment", and it's considered
    to be a feature, not a bug. Most functional languages, including ML
    and Haskell, also behave this way. Among other things, It's nice
    being able to rely on a certain variable always having the same
    value.)

While not the most compelling defense of FP I've ever seen <ahem>, they do
know their audience!  That's all to their credit.

I *like* the attitude of the Erlang developers.  Looks like a very useful
language for its target domain.  Even better, according to FAQ 5.7.11
there's a Python binding (if you really need some higher-order functions
after all <wink>).

if-we-don't-act-fast-i'm-afraid-python-may-lose-the-industrial-
    control-market-ly y'rs  - tim