Larry Wall wrote:
It's really, really easy to misdesign a computer language by
overemphasizing one particular design dimension to the detriment
I agree that adding a parallel "forall" (and similar statements) via a
pragma will be easy if the appropriate underlying machinery is there, so
maybe I can live with the bias in S04 -- perhaps rename it to
"Sequential Blocks and Statements". Anywhere that we guarantee
sequential behavior, we pretty much rule out concurrency. But if we
maximize the number of places where we are explicitly "unordered" then
we also maximize the number of places where implicit concurrency can be
added later. From that perspective, it's unfortunate a C<for> loop
always iterates arrays in the order of their indices.
As I see it, parallelism is easy: it's synchronization that's hard.
Specifically, it's hard to get exactly the right scoping of constraints.
And it seems to me that "hyper" addresses the parallelization aspect but
not synchronization. Concurrency.pod (S17) defines a few basic
mechanisms, but it's not obvious that they're really "easy", or
sufficiently declarative. There seem to be synchronization scopes
analogous to "state" and to hypotheticals, but not "my", "our", "temp",
and "has". (I'm not sure exactly what primitives are needed: we could
discover that by doing more parallel programming ... which won't happen
unless it's easy)
The way humans seem to work is that they'll say "I'll do this and this
separately, but I won't worry about that unless something goes wrong".
We employ a mixture of course grain threading, fine grain locking,
exceptions, and recoverable transactions; that we juggle dynamically.
That's pretty hard to do when writing a program, which is why I want to
place the burden on the language designer, not the language user.
With Perl 6 we're trying to make the opposite mistake.
I fear you may be successfully underemphasizing one dimension to the
detriment of others :-). But considering that you do a pretty good job
most of the time, I'm not too worried.