[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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. :-)