Processing-Mode Equality

[Zhong Yu]

On Sat, Feb 8, 2014 at 3:56 AM, Graham Allan <grundlefleck at gmail.com> wrote:
> Hi Maurice,
>
> Seems like Brian's explanation is slightly mismatched with what you
> originally had in mind.

My impression is that the Stream interface is parallel only. It does
allow user to specify parallelism level = 1, a.k.a. the sequential
mode. The main reason for the sequential mode is that a lot of Java
programmers are imperative-minded, and they'll want to pass in
functions with side effects.

Zhong Yu

> Given that, how about: "Principle of Optimistic
> Parallelism"*. That the API was designed with the expectation and hope (but
> not decree) that the user takes advantage of parallel processing. Not sure
> it quite covers functional equivalency though.
>
> HTH,
> Graham
>
> * or "Parallelism Optimism" if you're in a rhyming mood.
> On 6 Feb 2014 15:56, "Brian Goetz" <brian.goetz at oracle.com> wrote:
>
> I like to look at this as having chosen a design center that recognizes
> that sequential is a degenerate case of parallel, rather than treating
> parallel as the "weird bonus mode".  I realize that this choice was
> controversial and definitely caused some compromises, but eventually
> people will have to start to unlearn their sequential biases, and
> there's no time like the present.
>
>  From the perspective of a hundred years from now, there is an optimum
> time in history to invert the primacy between sequential and parallel in
> programming-model design.  (For example, 1995 would definitely have been
> too early.)  That people are made uncomfortable by this subtle shift in
> priority might indicate that 2014 is also too early, or might simply
> reflect the fact that that people are always uncomfortable about change
> and whenever we did it we'd suffer the friction of people clinging to
> their increasingly unhelpful sequential assumptions.
>
> In any case, my perspective is not so much that there are two modes and
> that they should yield equivalent -- though not always identical --
> results (though this is true), but that one mode is a degenerate special
> case of the other, and we have chosen to focus (most of) our design
> effort on the general case, rather than catering to the special case.
> (We made a few exceptions, and overall, we may well have made too many
> exceptions rather than too few.)
>
> I realize people may disagree with our approach.  People are very quick
> to point out what they perceive as losses -- say, the lack of a
> takeWhile or other fundamentally sequential operation, and bemoan "why
> couldn't you just have made it a sequential-only operation?".  But what
> they usually don't see (or at least never say out loud) is that taking
> the general approach pays a simplicity dividend -- that we don't need to
> reason about special cases like "this operation is sequential-only."
> Irregularities breed complexity.
>
>
>
> On 2/6/2014 7:18 AM, Maurice Naftalin wrote:
>> In writing about streams, I want to explain how the API has been
>> shaped by the design goal of maintaining functional equivalence
>> between parallel and sequential execution. I'm looking for a name for
>> that goal, but so far the best I've come up with is the Principle of
>> Processing-Mode Equality, which is pretty clumsy. I'd appreciate
>> suggestions for improving it (which I will be happy to attribute).
>> Thanks in advance!
>>
>> Maurice
>>
>