I may want to stay with Perl 5 rather than go to perl 6. But there is a problem in staying with Perl 5. Due to Perl 6 the Perl 5 community is deprived of the resources of several key people, e.g. Larry, and also "Good Damian".

I wonder if Parrot will be further delayed due to the need to support Perl 6, when a Perl 5 oriented Parrot might be done much sooner.

Ruby holds little appeal for me, and Python even less.

I think it is telling that most of the responses to my email are a technical discussion, e.g. how to make Perl more like Scheme. But Scheme, while elegant, is still a "boutique" language whereas Perl is widely used.

As we know, when Larry designed Perl he took the best parts of awk, C, sh, etc., plus added a few excellent new ideas, and produced a language that was a mixture -- but a mix based on features that had been proven to be good.

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. 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.

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.

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.

But I admit that the Apocalypses are scary stuff when taken on an empty stomach. I expect everyone to panic at least once, on average. Some of us have already panicked several times to make up for those who haven't yet. :-)

You already know how topics work in English, so we try to take advantage of that. You know how to express hypothetical ideas, so we'll try to take advantage of that too. You know how to explain something in terms of something else. That's how the classes and properties and traits are supposed to work together. Perl 6 will work more like a natural language than Perl 5, but it's still nowhere near the complexity of English or Japanese. Or Swahili, for that matter.

It seems to me that Perl 5 maps well onto, say, English, but now it seems like you're trying to map (parts of) Perl 6 onto something else ... a way of looking at things. I don't quite have the vocabulary to explain it, especially this late on a Saturday night, but it seems to me that this sort of a mapping is odd. Topics and hypothetical ideas? 2 + 2 might equal 4, but only when not driving a truck?

I disagree almost completely.

• Perl 5 gained a tremendous influx of new people and ideas after the announcement of Perl 6. PerlIO, Perl QA, the Perl6:: namespace on the CPAN, the defined-or operator, locked hashes, assertions...
• There have already been two "Perl 5 oriented Parrot" projects: Sapphire and Topaz. They were done much sooner in the sense that they've been long dead.
• Several of the features you call "theoretical" have had practical benefit, some for decades. I don't understand where to draw a line between "adding proven features from other languages and a few new features is good" and "adding proven features from other languages and a few new features is good". They both read the same way to me.
• I've met very few practicing programmers who could actually read code well.
• It's way too early to complain about Perl 6 error messages when they haven't yet been written.
• The original design of Perl was simple, if you had experience in Unix, sh, C, awk, and a few other languages you'd probably call "boutique".

I'm sympathetic to the fear that Perl 6 is hard to understand. I certainly haven't wrapped my brain around it, but it's starting to sink in over time. There are deeper consistencies you're not seeing yet, partly because the whole design hasn't emerged and partly because you're used to some of the quirks of Perl 5.

I just don't think the facts really support your other arguments, though.

But those are not the types that read the Apocalypses anyway.
Then there are those who know Perl5 well and are content with their possibilities. They are probably best off using that part of the language they know. Then there shouldn't be the need to learn more (except details, but hey those can even change in maint-releases in Perl5).

And then there's us.
I'm not content. I want to do more with less (syntactic hassle that is). I like to see theoretically desireable features in Perl6 because I'm missing some of them, or don't know some and would like to try them out.
Without turning to some exotic language I can't find support for, and no application at hand.
I know a couple of people that are like me: Try those sick things because they're there to play with.
I learned quite a lot by just doing stuff I didn't grasp when I began playing and then gradually getting the hang of that.

Of course it's a problem if that's the only way of learning one is capable of, but I find it's one of the most effective ways there are.

To people who don't grasp error messages caused by using concepts they don't understand, I like to quote MJD to: "Well, if you don't know what it does, why did you put in your program?".

If they want to know I always have the time to explain.

Over lunch or a decent malt. On weekends, too.

janx

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.