develooper Front page | perl.perl6.language | Postings from March 2005

Re: "The fate of reduce() in Python 3000"

Thread Previous | Thread Next
Luke Palmer
March 13, 2005 21:48
Re: "The fate of reduce() in Python 3000"
Message ID:
A. Pagaltzis writes:
> Hi all,
> so Guido is talking about his reasoning behind dropping lambda,
> reduce(), filter() and map() in the next generation of Python:
> [Prime quote: "I think having the two choices side-by-side just
> requires programmers to think about making a choice that's
> irrelevant for their program; not having the choice streamlines
> the thought process."]

Hmm.  As people have pointed out, this is essentially reinforcing a
Python philosphy:  TOOWTDI.

Guido's point about map and filter I can understand.  He points out that
both of them can be easily transformed to list comprehensions.  He's
using a design philosophy that Java started with:  when you give
programmers fewer choices about how to do something, the probability
that they'll do it in the conventional, widely-understood way goes up.  

Where Guido's philosophy falls down is around the Hard Things.  Many
problems can be solved easily with simple procedural code.  But when you
run across a problem that can't, say, in programming an AI, then you
have Python programmers doing a *lot* more work than Prolog programmers.  
So in that regard, I think dropping lambda and reduce is idiotic.
Dropping filter and map is not; there's another WTDI which does the
exact same thing.

That's certainly not Perl's philosophy.  Perl intends to be
multiparadigmatic so that whatever your programming background, you can
find a sweet spot in Perl.  Of course, that makes it hell for most
people reading code who don't have backgrounds in every paradigm.  But
Perl and CPAN culture facilitate that quite well: unlike in Java, CPAN
modules' documentation is separate from the code structure.  This
encourages authors to write something *useful* about their module, to
explain their module to the most basic programmer.

What can we reap from Guido's reasoning?  It's actually pretty simple, I
think.  He found two functions which were doing the same thing as list
comprehensions, and so he got rid of them.  If we see one feature that
can always be done as easily or more easily with another feature, it can
probably go.  Note that I'm not identifying "easy" with "short".  If
feature A can always be expressed more concisely with feature B, feature
A may deserve to stick around for those people who don't understand
feature B yet.  Hyper operators come to mind.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About