The current differences between Java and Perl on this issue are that currently Perl's bytecodes are not a standard that is written down somewhere, and Perl's bytecodes are designed around units of action that make sense for scripting. Java's are written down in detail, and are designed to create something that looks like a virtual machine. I don't think that making Perl's bytecode into a written standard is going to be that big of a problem.

I would prefer that references kept -> and. would get used for methods and properties and stuff. But I'll live.

Ageed.

But I doubt it will end up feeling optional after a few more C programmers are converted.

Converts from C already have to have for(;;) beaten out of them. However, IMHO the code that really matters is what everyone more or less has to use; in the Perl world, that equates to CPAN. Therefor I rest soundly at night (so long as I don't have other worries).

I use _ a lot in variable and sub names, but I tend to do most my concatenating using interpolated strings anyway.

Remember that the new concatenation operator will in effect be "space underscore space". Underscores embedded into identifiers don't get mistaken for concatenations.

What I'd really prefer is a way for me to do something like $name = sub{ return 'My Name' }; print "$name\n"; without having $name return a darned coderef value rather than the results of $name->().

You can already do something akin to this using overloading. It is extra code, but you can neatly package it away. (See "Falsify" scalar strings for a quick overview of how to use overloading for sorcery of this kind.)

And as far as the bytecode is concerned, rest safe in the knowledge that every single modern interpreted language uses bytecode compilation in some way. As already mentioned by tilly++, but maybe not emphasized strongly enough, the difference between the Java and Perl bytecode is that Perl5's bytecode is very high-level - in fact, for a number of builtins, a call to them results in a single VM instruction. Java's VM on the other hand is very low-level and tries to mimic real hardware. That is the reason why Perl is fast and Java is slow. That's not going to change. Perl 6 is just bigger and better than Perl 5 in that respect. That's all there is to Parrot - more of the same, with some extra spice and lots of chilly.

Maybe in contrast to my posts here so far, I don't think I'll enjoy Perl 6 as much as Perl 5 for a while to come. Perl 6 will be new, unfamiliar. I'm sort of an old dog in Perl 5, not nearly as much as others but I consider myself fluent in it and have no trouble finding my way around things and pronouncing ideas such that I can express them in a Perl5ish, idiomatic fashion. It will take everyone a while to achieve this level of familiarity in Perl 6. What I'm really looking forward to is using Perl 6, after having already used it for a year.

I have to disagree with you here. What's wrong with the following?

my %SomeHashWithCoderefs = (
    FOO => \&foo,
    BAR => \&bar,
    BAZ => \&baz,
);

sub Switcheroo {
    my @conditions = @_;

    # Using the @conditions, return 'FOO', 'BAR', or 'BAZ'
}

# In some main area...
$SomeHashWithCoderefs{Switcheroo(@args)}->(@otherargs);
[download]

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Because FOO, BAR, and BAZ are not conditions, they are static labels. Is there a way to get them to behave as ranges or any sort of boolean? If so, I still don't have a problem with switch, but I would be glad to have another trick up my sleeve. :)

Yah, there is.

sub Switcheroo {
    my @conditions = @_;

    if ($conditions[0] < 10) {
        return 'FOO';
    } else {
        return 'BAR';
    }
}
[download]

The point is to encapsulate the strategy of determining which direction to go. That's what a switch statement does. This is, basically, a Switch object. (An example of a Strategy pattern, for those following along at home.)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.