I don't care about the sigil stuff that much, although I agree that it is better in the long run not to have to shift the sigil to say what you mean. I prefer the Ruby use of sigils to denote things like scope levels ($ for global, @ for instance, @@ for class).

I don't care about the dot much either: no other language I've used has -> for methods. I would prefer that references kept -> and. would get used for methods and properties and stuff. But I'll live.

Everything as an object. Been there, done that. See also: Ruby.

"Optional" strong data types. A natural extension of the previous point. But I doubt it will end up feeling optional after a few more C programmers are converted. One thing I like a *lot* about Perl is the ambiguity of the scalar. This is serious erosion of that, imho.

I'm not sure I understand these hyper-operators. From japhy's example they look like pre-coded versions of the block/yield structure in Ruby with a bit of Tie thrown in (method overloading essentially). Which is fine with me if there are considerable performance gains to be had-- otherwise I think these will confuse Perl newcomers and oldcomers alike for quite a while.

Totally unthrilled that _ will be the new concatenation operator since I use _ a lot in variable and sub names, but I tend to do most my concatenating using interpolated strings anyway. 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->().

Switch? Not terribly big deal to me either way. I can see it's value if you want to do some sort of goto-based dispatch, and yes I consider it an improvement over a hash full of coderefs since the conditions in a switch can be more involved that the simple labels that are hash keys. Enough languages have this that there's no reason to avoid it.

The only thing that keeps from seriously saying "Yeah, but there is *already* Ruby available" (since 99% of the above seems to be already implemented in Ruby, which can be very Perlish if you want it to be) is the byte-code issue. And frankly, the byte-code thing scares me. Two reasons: Java seems to have taken off, but is this because it was an OO language with a good sense of community at a time when the alternative was obscurity and/or C++? Did Java succeed because so many people learned it based on the dreamy notion that it would allow web browsers everywhere to essentially become OS replacements-- only to find out that it worked much better as a locally compiled/executed language? But AFAIK Java is the best example of a language with a VM. And I don't still don't get a coherent sense of whether the public has made a real decision about the Java VM.

And so I wonder if this isn't a major mistake for Perl. Will it actually be fast enough to follow through? Will it actually be portable? Will it promote the distribution of byte-compiled code under proprietary licenses?

And those are my thoughts as a fairly uninvolved Perl user and one who thinks Ruby probably solves a lot of these problems already (in addition, from what I understand, extending Ruby with C neither requires the Inline module or XS hacking). If the byte compiler/vm comes to pass and I can truly write in other languages (such as the aforementioned Ruby-- and if Dan Sugalski has anything to say about it, I'm sure I'll be able to) for it, then I'll be very happy (other misgivings aside). A good vm would be much preferable to the shared library/dll situation, since it would make sharing Perl and Ruby code to Windows users who are not hackers a lot easier.

PS: wrt to tilly's comments on byte code... woohoo! I have much more confidence in that aspect now. *grin*

In regards to the bytecode issue, how do you think that Perl works now? It turns out that Perl compiles your program to bytecode and runs that in a VM! We just don't advertise it that way.

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.

Switch? Not terribly big deal to me either way. I can see it's value if you want to do some sort of goto-based dispatch, and yes I consider it an improvement over a hash full of coderefs since the conditions in a switch can be more involved that the simple labels that are hash keys. Enough languages have this that there's no reason to avoid it.

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

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.