Updated State of the Lambda

[Dan Smith]

On Dec 12, 2011, at 3:21 AM, Stephen Colebourne wrote:

> int sum = list.map(e -> e.size()).reduce(0, (a, b) -> a+b);
> 
> I continue to find map/reduce examples for summing a list to be
> troublesome. I remain concerned that the mental shift involved here is
> being underestimated, particularly in the context of Java.
> Specifically, steps that are currently performed as one, are now
> having to be broken down into multiple parts - map then reduce. Note
> that I do not think that individual filtering or transformation of
> lists/maps will prove troublesome, my concern is primarily around
> multi-step operations and reduce.

Well, you can always perform the steps as one if you want:

int sum = list.reduce(0, (n, e) -> n+e.size());

Should we be criticizing this alternative as a Bad Thing?  I'm not sure there's a clear reason to do so.  I think the use of chaining in these toy examples is inspired by much bigger problems where there's a clear benefit to separating concerns.  (And in this particular case, the use of chaining evolved from a time when we were using a 'max' method.)

> I continue to be concerned about the verbs being used and their
> readability. Clearly these terms are used elsewhere, but I continue to
> be of the opinion that "map" is the wrong verb for Java, because of
> Java.util.Map. My preference currently remains as
> "transform/Transformer". Similarly, I think "combine" may be a better
> verb than "reduce". With altered verbs, I think the mental shift
> required is lessened:
> 
> int sum = list.transform(e -> e.size()).combine(0, (a, b) -> a+b);

+1 on 'combine'.  'map' doesn't bother me (I'd even like to see Map implement Mapper :-) ), but 'combine' seems to clearly convey the behavior more explicitly than 'reduce'.

—Dan