i apologize for my rather immature first post. i clicked the "make your petition" link and was under the impression that i was beginning a petition. it seems i am not :)
i will concede that i don't know too much about perl 6. i am relying mostly on the exegeses on dev.perl.org. here are some of the problems i've seen:
1) to me, parrot seems frivolous and unnecessary. it reminds me very much of java's virtual machine, which, from my experience seems pretty bad. why should we concern ourselves with making a platform that can run different languages? perl 6 should be about perl, not about a virtual machine
2) the use of . instead of -> and _ instead of . utterly disgusts me. why should this be changed? unless objects are no longer references in perl 6, there's no reason for this switch except to appease vb and java programs. at the very least, . and -> should be synonyms. and _ is an ugly way to concatenate:
print "sdsd" _ "dsdsd";
i'm not saying that perl 5 can't be improved upon. XS could be made much prettier, and better module exporting methods could be used. but rewriting the whole thing and twisting its syntax to ugly javaness is hardly necessary.
also, i am not a troll (at least not intentionally :) )

(Note that this is all based on my limited knowledge of Perl 5 and 6 as they are now.)

Syntax, as I recall, will be alterable at the file level (and others), and so the changes will then be to the default syntax, as opposed to the only syntax. Also, I disagree with you about Parrot not being good; I would very much like to be able to, say, write programs in Ruby and be able to access the vast library of Perl modules in CPAN, or write programs in Perl but using a few Python modules. Perl 5 already does use a virtual machine of sorts; it's just not explicitly exposed, which makes it less orthogonal and more difficult to at-get in a standard fashion.

I am glad we're making a platform that can run different languages. Parrot has the potential to pull much of the dynamically typed language community together and can give it a solid footing. If there is a great Python library that I want to use, I can run it through Parrot and use it from Perl without much effort. You can also use Parrot assembly directly from Perl and get the performance benefits without being forced to learn C. And the JIT compiler will be a godsend for many programmers. It will be wonderful to compile and distribute an actual application, rather than many of the hodgepodges that we have now.

the use of . instead of -> and _ instead of . utterly disgusts me.

The underscore is there because the dot operator no longer represents concatenation. As for the dot operator, once I became used to the change, I was happy for it. First of all, it represents less punctuation. Whether justified or not, many people gripe about Perl's excessive and sometimes confusing punctuation and this will help to alleviate that concern. Of course, if one is going to reduce punctuation, one should do it for commonly done things. The arrow operator is one of those things and since everyone else already uses the dot, it's a pretty natural conversion.

Incidentally, take a look at some VB6 or VBScript code and compare it to the code written for Win32 modules. Quite often, lines of code are identical, except for the difference between the arrow and the dot. This makes less of a barrier for people coming to Perl. We shouldn't be here to be elitist. We should be here because Perl Gets Things Done. If switching from an arrow to a dot improves that and makes Perl seem less intimidating, so be it.

Returning to the punctuation problem, the shift from arrow to dot is part of the overall plan to extend Perl yet make it easier to learn. This has led to standardizing the sigils of variables so that they denote type instead of what the variable is returning. For instance:

The above syntax is already what many new programmers expect out of Perl5. We have to violate their expectations to explain the difference between accessing a single array value or an array slice. Further, the following monstrosities in Perl 5 can hopefully go away:

@_[1..$#_]; # all but the first element of an argument list
@{$var}{qw(foo bar)}; # a hash slice of a hash reference

Also, the "." syntax has one big advantage: topics. When calling a method on the topic ($_ (also $self in OO -- see article on perl.com)), a lone dot looks much better than a lone arrow. .method vs. ->method And it fits my brain better for assignment.

now, wait just a tick. are you saying that parrot will allow the use of non-perl libraries and that it will allow true executables (not perl2exe or perlapp packages, but real exe's)? if so, then i just might have to retract my anti-parrot sentiments.

Non-perl libraries yes. You can do it now if you're so inclined--the code to handle it dynamically (i.e. without having to build an extension to wrap the library) is in the repository now.

You should also be able to build standalone executables, though whether there's any speed win is up in the air. (And you can certainly write code such that you can't have a standalone executable if you so choose...)

This area is for discussion of the Perl Monks site. If you want to start a discussion about Perl 6, that should probably go under Meditations, unless it is a specific question in which case it goes under Seekers of Perl Wisdom.

From what I've read of the Apocalypse and Exegesis series (which, admittedly, was only the first few a long time ago), I think some of the 'punctuation' changes you talk about were being made because of ambiguities in the perl5 syntax. Certainly, any change that allows the programmer to get his wishes across to the compiler with less confusion can't be all bad.

It seems your first experience here has been a trial by fire, but it's good that you haven't taken it personally :^)

With respect to your comments about Parrot, it is important to note that Perl has always been an interpreted language, and therefore run on a virtual machine, namely perl. The difference in Perl 6 is that the compiler and interpreter (VM) are separated from one another, something like the difference between javac and java. So the question is not whether there should be a VM, but what it should do and how it should stand in relation to other tools and languages. My understanding is that the affordances made that allow Parrot to run multiple languages (after compilation to bytecode) also enable functionality like syntax modification, which pushes Perl toward Wall's goal of a metalanguage. So the design choice both increases Perl's flexibility and provides greater options to other languages.

As to the aesthetics of -> vs . and . vs _, these debates ultimately must take a backseat to what works. When I started coding in Perl after using Java for a couple years, I was mortified by sigils ($, %, @, etc.) and the arrow syntax. After three years of Perl, I've gotten used to them and often compulsively type them now regardless of language. Besides, there are always source filters and various pragmas to enable you to customize the way you want to write your code.

You've not spent any time dealing with perl 5's VM, then. The current virtual machine (and it is a virtual machine, make no mistake there) has a number of... issues that make extending it, changing it, or otherwise doing much to (or with) it really painful. This is in part because of some issues with the original design, and in part because of seven or eight years of continuous hacking on it by a wide variety of people.

Just because the JVM (and the .NET VM) made some fairly fundamentally bad design decisions doesn't mean that all VMs are bad. (And I'm interested in what similarities you see, as there's almost no overlap at all, from an architectural standpoint)

to me, parrot seems frivolous and unnecessary. it reminds me very much of java's virtual machine, which, from my experience seems pretty bad. why should we concern ourselves with making a platform that can run different languages? perl 6 should be about perl, not about a virtual machine

There are lots of reasons people are paying attention to parrot (in addition to the fact that playing with VMs is fun :-)

Most important is probably the fact that the perl5 VM is a god awful mess. It's hard to understand. It's hard to extend. It's hard to maintain. It was a very obvious component of perl that needed a complete re-write.

Personally, I think multiple-language support is a good thing. Writing code in multiple languages is useful, and very few environments allow you to do it in any meaningful way. I talked about this a little bit elsewhere if you're interested. Supporting multiple languages in this way is, to me, a natural extension to Perl's TMTOWTDI attitude.

Also, making the VM more explicit and straightforward makes things like writing JIT compliers a much more practical goal.

Finally, having explicit access to the VM and various compilation phases from perl6 enables you to do really cool things. Not more messing with subroutine prototypes or source filters. You can actually write your own syntax.

(Actually, I'm not 100% on this being in the perl6 goal list - not having to spare time to do more than read the weekly summaries... but it's certainly possible).

the use of . instead of -> and _ instead of . utterly disgusts me. why should this be changed?

Well, these sorts of decision are, to some extent, a matter of taste. However the changes were not made arbitarily. Three good reasons come to mind.

Typing two characters all the time when one would do is a waste of time and space.

The fact that practically every other language on the planet uses the "." notation for this sort of thing adds a pointless comprehension barrier for people who switch between languages.

I believe (not 100% on this) that perl6 changing so that the syntax for method access and direct attribute/field access is the same (so $foo->method and $foo->{field} would be written $foo.method & $foo.field). This is a very good thing since it allows you to change your implementation without changing your APIs. Sensible languages like Eiffel have been doing this for years (see this article for more info on why this is good.)

I remember similar arguments when "::" replaced "'" as the package separator. With the exception of Klingon, I don't think anybody worries about it any more.

If you're interested (and have the spare time) I would spend some time wandering around the perl6 mailing lists. There's a lot of interesting stuff, and it will give you more background on why certain decisions have been made.

Personally, from what I can see so far, perl6 is going to provide me with many of the features that I have sorely missed in perl4 and perl5 (proper OO, ability to write your own domain languages, simple currying, etc.)

There is also the fact that so much of perl5 stays exactly the same in perl6. Only the changes get talked about.

While I don't agree with every design decision that's been made the changes are certainly not being made just to annoy. If I had more of that mythical substance known as "spare time" I would contribute to the implementation effort (and get some input to those designs decisions I'm not 100% happy with). If you have the inclination, and feel that you have something to contribute, maybe you should consider it.

Others have already implicitly mentioned this, but I think it's worthing noting once more explicitly because a lot of people misunderstand this point.

Perl 5 runs on a VM.

It just doesn't have a name and is hidden in there along with the compiler. The result is that next to noone seems to notice that Perl5 has a VM just like - and is no more interpreted than - Java and others.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other