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

[Erik Max Francis]

Ron Adam wrote:

> But together, sum and product, probably cover about 90% of situations in 
> which you would use reduce.  Getting a total (sum) from a list probably 
> covers 80% of the situations reduce would be used on it's own.  (I can't 
> think of any real uses of product at the moment. It's late.)

It's not uncommon in mathematics to do repeated products.  If you're 
familiar with the capital Greek letter sigma notation, if it's replaced 
with a capital Greek letter pi, then it's an iterated product, rather 
than an iterated sum:

	http://mathworld.wolfram.com/Product.html

In general, pretty much _any_ operator can be replaced in this symbol to 
indicate a repeated operation.  Function composition, set unions and 
intersections, logical conjunctions and disjunctions, direct sums and 
products, the list goes on and on.

> 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?

I'm not myself a huge functional programming guy, but I'm certainly not 
in favor of the proposal to remove map, filter, reduce, and lambda.  For 
map and filter, I can at least see the argument, because they truly are 
expressible with list comprehensions (which I do use myself, of course). 
  lambda I also don't buy, but at least there, yes, you can just define 
a local function and use it locally, although I think expressively that 
it skirts the line between expressivity and verbosity (if you know what 
lambda is, straightforward use of lambda is not at all unclear, in fact 
it's quite clear).  So at least there's something to that, but I don't 
follow it the whole way.  But removing reduce is just removing 
functionality for no other reason, it seems, than spite.

-- 
Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
   Who knows whether any of us will be around in 1972?
   -- John F. Kennedy