No 'fold left' without a combiner ?

[Brian Goetz]

>> Adding a handful of sequential-only operations may make certain use
>> cases easier, but there's a hidden cost -- reasoning about stream
>> pipelines becomes harder for everyone, because now parallel
>> compatibility becomes an element of the model which must be
>> considered.  Short-term gain, long-term pain.  No thank you!
>
> so for my example, the idea is to *not* use a stream and use a for loop
> instead, right ?

The idea is to do what feels like natural code.  We've not outlawed the 
for-loop.  There will be places, obviously only in sequential cases, 
where for-loops are simpler, easier, faster, or more natural.  Whether 
to use a loop or a stream pipeline depends on how much else the stream 
is doing.

For example,

   list.stream().reduce(...)

could just as easily be a for-loop, and at that point, its a 
pick-your-poison thing at this point (the imperative for loop or the 
streamy reduce that makes you specify an extra argument.)  But if you 
were doing

   list.stream()
       .map(...)
       .filter(...)
       .distinct()
       .reduce(...)

going back to a loop would be giving up a lot.