Report: Will Java 8′s Lambda Change The Face of The World?

[Brian Goetz]

> Before fold, there was a mapReduce method, with almost the same
> signature. I have presented this method. But it has not convinced the
> audience. That fact is that the map part and the reduce are separated.
> The audience has not understood why they are separated.

With the existing API, it is possible to "fold" the mapping into the 
combiner if you want -- have your reducing function be (sum, elt) -> sum 
+ map(elt).  But a single method with two lambdas is not going to be 
more usable -- people will have to reason about which lambda does what 
based on position.

The current configuation of reduce and fold methods is scheduled to be 
revisited.  But I don't see much merit in a fused mapReduce(Mapper, 
Reducer), other than the ability to do the computation in the primitive 
domain rather than the boxed domain -- and we have another approach for 
that.

>> 2. Current documentation suggests stream methods should not be on collection
>> interfaces to not bloat them since there is no single stream implementation.
>>
>> e.g. products.stream() vs products.parallel()
>
> I understand this. But the result is that we have to use an
> intermediary method call that looks like noise addition in the method
> chaining for the audience. This is not really intuitive.

Understood.  This was a difficult trade-off.  In fact, I resisted this 
for a long time.  But in the end, it was clearly the right choice.  When 
you are retrofitting functionality onto existing libraries, sometimes 
you must choose the lesser of evils.