in reply to Multi-core and the future
The multicore boom is just as silly as the mega and gigahertz race. No-one really needs that much computing power. When I say no-one, I really mean it: you think you do, but in reality you could do everything you do now with machines from ten years ago. The obsession to produce faster and leaner computing units yearly, quarterly, and even monthly is sometimes fun to watch, but it makes you think if there wasn't a better target for all that intellectual and financial effort.
Rambling aside, my firm belief is that parallelism implementations and techniques should be invisible to the user of the programming language or library. This isn't to say they shouldn't be available; on the contrary. Having trivial to use implementations that prevent you from programming race conditions or deadlocks is crucial.
Consider sorting in standard libraries of any programming language. Most of the time you use the standard mergesort or quicksort. You don't need to know how the implementation was done; you just feed in an array and out pops a correctly sorted one. Parallelism is a harder problem than sorting, so the interface can likely never be this simple, but ideally all you would need to do is define which pieces of code may be run in parallel, and the language implementation would do the rest.
The obvious benefit is that the programmer can then make less of a mess of it. Parallelism is hard in the general case, but there are many good solutions to the problem. There is no reason why you should have to manage threads or mutexes yourself, unless you are writing the library code. We already have automatic memory management; we should have automatic parallelism.
Note that the above remark is not condescending. It is just wasted effort and time when you insist on doing something manually that could and should be automated. No offense to C programmers either!
Perl 6 comes very close to the ideal, I think. It might develop even closer. Hyperoperators and junctions are an excellent start, though I haven't seen any documentation or planning how they will work with side effects (for example, two functions &foo and &bar assigning to the same variable). Obviously it was meant to be used in SIMD and MIMD operations, not like this, so there is still a long way to go. Quite a lot of research has gone into parallelism (sometimes called multiprogramming, which has a nice sound), and threads or mutexes or monitors are not the only options. The problem is, as always, finding a good compromise.
Since Perl 6 is not side-effect free (unlike, say, Haskell, unless you do I/O), it won't be as convenient to describe to the compiler which code blocks depend on each other and which ones don't -- though there may be a way through analysing lexical variables. In any case, in the first version of Perl 6 parallelism and concurrency won't be revolutionary.
--
print "Just Another Perl Adept\n";