stream() / parallelStream() methods

[Brian Goetz]

> Well, I don't like the parallel() method on Stream anyway, so I'll
> let others take over from here...

You can't drop a bomb like that and walk away!  You have to explain why 
you don't like it, because I suspect most people's first guess about why 
will be wrong.

I'll take my best stab at explaining why: because it (like the stateful 
methods (sort, distinct, limit)) which you also don't like, move us 
incrementally farther from being able to express stream pipelines in 
terms of traditional data-parallel constructs, which further constrains 
our ability to to map them directly to tomorrow's computing substrate, 
whether that be vector processors, FPGAs, GPUs, or whatever we cook up.

Filter-map-reduce map very cleanly to all sorts of parallel computing 
substrates; 
filter-parallel-map-sequential-sorted-limit-parallel-map-uniq-reduce 
does not.

So the whole API design here embodies many tensions between making it 
easy to express things the user is likely to want to express, and doing 
is in a manner that we can predictably make fast with transparent cost 
models.