Re: Accumulator

[Adam Turoff <address@hidden>]

On Thu, May 23, 2002 at 11:09:30AM -0700, Paul Prescod wrote:
> Pixel wrote:
> > ...
> > well, you didn't talk about "reduce". The main pb with list
> > comprehensions is that they are limited to giving lists as a result.
> 
> reduce is used roughly once in the 50,000 lines of code that are the
> Python standard library. It clearly is not pulling its weight. In a
> project I worked on with six different Python programmers, ranging in
> expertise from guru to newbie, nobody used it once.
> 
> "reduce" may be the right thing for Lisp programmers but we have
> concrete proof that it is not the right thing for Python programmers.

That's a very weak argument.

I've seen sample code for writing web clients in Perl that is much
simpler to maintain and extend in a functional style.  The example
takes a couple of classes from LWP (Perl's libwww) and the required
control structures to spider and perform link checking, and implements
something *more* functional and extensible in roughly half the code.

This is a Perl vs. Perl comparison that highlights object style
vs. functional style.  What's interesting here is that the code
that *uses* these modules is a lot simpler, because the transformations
are described declaratively in setup code.  A lot of the standard
options are simplified because they are implemented through the
layering of closures by the module user rather than done with lots
of option-checking by the module author.

I'm finding that Perl (to name one language) needs to go back to
McCarthy's well for some more inspiration.  Thankfully, since
closures are first-class constructs in Perl, we're talking about
inspiration more than full-scale language reform.  I'm surprised
I've never come across Lisp-style generators, iterators and filters
before.  They go a long way towards generic programming without
the hideousness of C++ templates.  :-)

Z.