map/filter/reduce/lambda opinions and background unscientific mini-survey

[Ron Adam]

Erik Max Francis wrote:

> Ron Adam wrote:

>> I'm just estimating, but I think that is the gist of adding those two 
>> in exchange for reduce.  Not that they will replace all of reduce use 
>> cases, but that sum and product cover most situations and can be 
>> implemented more efficiently than using reduce or a for loop to do the 
>> same thing.  The other situations can easily be done using for loops, 
>> so it's really not much of a loss.
> 
> I really don't understand this reasoning.  You essentially grant the 
> position that reduce has a purpose, but you still seem to approve 
> removing it.  Let's grant your whole point and say that 90% of the use 
> cases for reduce are covered by sum and product, and the other 10% are 
> used by eggheads and are of almost no interest to programmers.  But it 
> still serves a purpose, and a useful one.  That it's not of immediate 
> use to anyone is an argument for moving it into a functional module 
> (something I would have no serious objection to, though I don't see its 
> necessity), not for removing it altogether!  Why would you remove the 
> functionality that already exists _and is being used_ just because? What 
> harm does it do, vs. the benefit of leaving it in?

There are really two separate issues here.

First on removing reduce:

1. There is no reason why reduce can't be put in a functional module or 
you can write the equivalent yourself.  It's not that hard to do, so it 
isn't that big of a deal to not have it as a built in.

2. Reduce calls a function on every item in the list, so it's 
performance isn't much better than the equivalent code using a for-loop.

  *** (note, that list.sort() has the same problem. I would support 
replacing it with a sort that uses an optional 'order-list' as a sort 
key.  I think it's performance could be increased a great deal by 
removing the function call reference. ***


Second, the addition of sum & product:

1. Sum, and less so Product, are fairly common operations so they have 
plenty of use case arguments for including them.

2. They don't need to call a pre-defined function between every item, so 
they can be completely handled internally by C code. They will be much 
much faster than equivalent code using reduce or a for-loop.  This 
represents a speed increase for every program that totals or subtotals a 
list, or finds a product of a set.


> But removing reduce is just removing 
> functionality for no other reason, it seems, than spite.

No, not for spite. It's more a matter of increasing the over all 
performance and usefulness of Python without making it more complicated. 
    In order to add new stuff that is better thought out, some things 
will need to be removed or else the language will continue to grow and 
be another visual basic.

Having sum and product built in has a clear advantage in both 
performance and potential frequency of use, where as reduce doesn't have 
the same performance advantage and most poeple don't use it anyway, so 
why have it built in if sum and product are?  Why not just code it as a 
function and put it in your own module?

     def reduce( f, seq):
         x = 0
         for y in seq:
             x = f(x,y)
         return x

But I suspect that most people would just do what I currently do and 
write the for-loop to do what they want directly instead of using lambda 
in reduce.

     x = 1
     for y in seq:
         x = x**y

If performance is needed while using reduce with very large lists or 
arrays, using the numeric module would be a much better solution.

    http://www-128.ibm.com/developerworks/linux/library/l-cpnum.html

Cheers,
Ron