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*

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.