functional programming

Neel Krishnaswami neelk at brick.cswv.com
Wed Feb 23 22:36:43 EST 2000


Tim Peters <tim_one at email.msn.com> wrote:
> [François Pinard]
> >>> What would be the advantages of using a "functional" Python,
> >>> as per your definition?  I mean, of course, in practice?
>
> I'll toss one in, since I don't think anybody else mentioned it yet:
> functional programs *can* be much easier to reason about.  NeelK
> nearly said as much in the case of threaded programs, but it applies
> to single-threaded programs too.

I'll agree with one caveat -- really serious FP'ers use lots of higher
order functions, and this can be quite tricky to think about in a
dynamically-typed language like Python or Scheme. Not necessarily
harder to prove theorems about, but harder to *think* about, if you
follow what I mean.

IME, Haskell and ML programers tend to use more HO functions than
Schemers, because they can use their nifty type systems as a ladder to
build up higher-order functions. But of course any statically-
decidable type system must reject some perfectly good programs, so
it's not pure win. 

OTOH, for any program where you don't need more than 2nd order
functions [*], then FP *is* pure win. This is closely analgous to the
observation that OO with classes is a pure win over procedural
languages, but that metaclasses give people headaches. The analogy can
be made rigorous with the correspondence between closures and objects,
and this will of course show the points where my observation breaks
down. (The times when metaclases are the right thing in an OO language
correspond closely to the times when making functions that return
functions that return functions is the right thing in an FP language.)

> Not long ago Billy mentioned an especially <wink> pure functional
> language called Joy, and reading the Joy papers should give a quick
> feel for how powerful and natural reasoning can be in a language
> aiming at that.  OTOH, Joy is useless <wink>.

IMO, it's the endpoint of the strongly-typed FP mafia's approach,
carried to its logical limit -- every Joy progam will terminate, at
the cost of the language's Turing-completeness. I *was* shocked by
just how much Joy *can* do: it pretty much sold me on the idea that
embedding Joy-style "extremely-pure" sublanguages in bigger ones is a
Good Idea.

[*] I mean every function either returns a non-function value, or
returns a function that returns a non-function value. This is second
order, right?


Neel



More information about the Python-list mailing list