RE: Accumulator

[address@hidden]

> -----Original Message-----
> From:	Paul Prescod [SMTP:paul@prescod.net]
> Sent:	Thursday, May 23, 2002 11:10 AM
> To:	Pixel
> Cc:	ll1-discuss@ai.mit.edu
> Subject:	Re: Accumulator
> 
> 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.
	[Bryn Keller]  
	Another data point, if anyone's interested: I have an application
which is also about 50000 lines of Python code. Reduce is used at least 15
times, and not always with operator.add, either. :-)

> "reduce" may be the right thing for Lisp programmers but we have
> concrete proof that it is not the right thing for Python programmers.
	[Bryn Keller]  
	Python's map, filter, and reduce *were* my introduction to
functional programming. They seemed odd at first, but I got to know them
(and lambda) better, and I began to appreciate their power, so now I don't
leave home without them. They may not be the right thing for *some* Python
programmers, but they're there and they work well, and I use them all the
time. I was a strictly object-oriented Java and Python user, who thought
Python's standalone functions were merely a historical vestige of procedural
programming (the fact and importance of their being first class dawned
mostly as a result of playing with map, filter, and reduce). Clearly I was
not a Lisp programmer, since at that time I was avoiding s-exp languages
like the plague. Since then, I've become familiar with a number of
functional languages, and I think there's real power there. I think
deprecating map, filter, and reduce is a serious mistake.