In contrast Perl 6 is a mixture of a variety of theoretically desireable features, e.g. multimethods, functional programming, logic programming, aspect oriented programming, design by contract, etc. that have not been proven in widely used languages.

With the exception of AOP I would say all of those have been proved widely. Multimethods are core to C++, which can hardly be called a minority language. Functional programming concepts have permeated many languages including perl5 (map, grep, closures, etc.) Design by contract is a programming methodology. It is done all the time in many languages - it just has little explicit support in most of them.

I agree that these features are theoretically desirable. But that does not mean they should all be put into one language. The thrust of the second system syndrome is the temptation to add all those other truly good features that the first system did not have.

They're not just theoretically desirable. I have some very concrete desires for many of the features in A6 because they will mean my code will become smaller, easier to understand, easier to maintain and considerably more elegant.

The claim that people will still be able to program in Perl 6 using a Perl 5 like subset is disingenuous. Most people read as much code as they write. The new language is much larger, and much harder to understand. It is likely to produce odd error messages, at least odd to people who have not taken courses in formal program language semantics.

I don't think it's "much larger". Larger certainly, but not much larger. There is a lot in perl 5.

I don't think there is evidence that it will be harder to understand. From what I have seen there is a lot of orthogonality in the design, and natural progressions from the simple to the more complex cases. What we don't have yet are the tutorials to make these progressions obvious.

While the perl6 stuff may seem more complex the thing people seem to forget is that doing the same thing in perl5 is even harder.

For example, multimethods in perl 6 introduce some new syntax. Writing the equivalent code in perl5 means more code and a more baroque design, or using Class::Multimethods. Both of which, I would argue, are harder to understand than the new syntax.

Am I the only person in the world who think perl6 is going to make code simpler, not more complex? :-)

The original design of perl was simple. I learned Perl 4 from its man page -- yes there was one long man page that completely described the entire language. Apocalyse 6 included almost 30 pages discussing the new ==> and <== operators! This is not a good sign.

Ah that's just language designers for you - they're not like us normal folk :-) Larry was discussing the rationale, background and all the ramifications. I bet the final POD will be something much more reasonable. For example:

LIST ==> LIST-OPERATOR

The ==> operator forces its left hand side into list context and passes it as *@ to the list operator on its right, forcing all other arguments of the operator into scalar context. So the following are all equivalent:

@foo ==> bar ==> ni($x);
ni($x, '*@' => bar('*@' => @foo));
ni($x, bar(@foo));
[download]

LIST-OPERATOR <== LIST

The ==> operator forces its right hand side into list context and passes it as *@ to the list operator on its left, forcing all other arguments of the operator into scalar context. So the following are all equivalent:

ni($x) <== bar <== @foo;
ni($x, '*@' => bar('*@' => @foo));
ni($x, bar(@foo));
[download]

would seem to cover it.