Processing-Mode Equality

[Graham Allan]

Hi Maurice,

Seems like Brian's explanation is slightly mismatched with what you
originally had in mind. 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
>