DevoxxUK Lambdas Lab

[Brian Goetz]

> I'm sure it was considered, but maybe something along these lines this
> might be more obvious:
>   stream.doThis().thenDoThis().reducing().doReducingStep().doReducingStep().collect(toList);

Extensively :)

> where reducing() returns a new type, such as ReducingStream (not
> extending Stream). In other words, the suggestion is to turn the
> "downstream" concept into part of the main method flow. No idea if its
> possible of course :-)

Not as far as I could tell :(

The problem, in a nutshell, was gathering the type information.  If you 
want to do:

   take transactions
   group by Buyer
   then group by Seller
   then map to transaction amount
   then reduce using max

The problem with such an approach is the type of the result, which 
should be:

   Map<Buyer, Map<Seller, Integer>>

Figuring out the type of the result "as you go" in a fluent manner is a 
mess.  That's why the current API takes a bottom-up approach, where you 
build Collectors and compose them, and the return type of

   groupingBy(T -> K, Collector<T, R>)

can be easily deduced as Map<K, R>, and composed arbitrarily many levels 
deep.

We also considered various "dumbed down" forms of reduction, like 
exposing groupBy as a top-level stream operation.  The trouble was, all 
of these were "one trick ponies", and no matter how many ponies you had, 
there was always a problem that was only slightly different that 
couldn't be solved.

The current API is a swiss-army knife that can do anything, and 
generally fairly elegantly once you fully understand it.  The last part 
-- getting people to understand it -- is the current challenge.