DevoxxUK Lambdas Lab

[Stephen Colebourne]

On 3 April 2013 15:08, Richard Warburton <richard.warburton at gmail.com> wrote:
> I'm not quite as negative as Stephen on the issue, because when getting
> people to try out the streams API I think broadly people have picked things
> up easily and been able to comprehend the problems quickly.  This is
> definitely one of the areas where they struggled a lot.

To be clear, I think some aspects of the API are conceptually easy and
fine, just labouring under bad names. filter() and map(). Others, like
sorted(), limit(), forEach, substream() are fine. Maybe flatMap(), as
it is limited in scope.

But collect() is both a simple pattern to learn, and a complex, hugely
powerful beast at the same time. ie. collect(toList()) can just be
learnt and is obvious once you see it. But the usage patterns of the
rest of the multi-arg collect methods are capable of a vast array of
uses, making it hard to find what you want. And reduction in general
is a big step.

In other words, my gut feel is that collect is doing too much. ie it
feels like simple problems are solved with nice methods, and for
everything else, there is some combination of collect and reduce that
will magically solve your problem if you happen to figure it out.

Documentation will help with some of this. But enough? Thats where I'm
more negative. It certainly feels like a even more radical jump for
Java than I was expecting.

Again trying to analyse this, I think its because the API mostly works
in a semi-imperitive style
 stream.doThis().thenDoThis().thenDoThis()

But collect(), doesn't feel like that. It feels like a bundle of stuff
piled high that magically creates an output. ie. the API manages
flowing data well, but reducing data less well.

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);
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 :-)

Stephen