Ever since hearing that Perl6 was forthcoming (eventually) and that it was a major rework (read: starting from scratch), I have been reading and playing with some of the new thingies that Dr. Damian Conway has come up with in his exeges. I've also been paying attention to the apocalyspes to get some foundation for what to expect.

I have come to look forward to any and all information related to Perl6. What I haven't heard, however, is much discussion about everyone's views on the inevitable changes tothe language. It looks like there will be significant changes both in what we will be able to do with Perl (more wonderful stuff) and on how we will be doing it. The addition of new data types and that everything will become an object in Perl6 will make us have to fundamentally change how to plan our Perl projects.

While I love Perl because you can use a scalar at any time to represent multiple "datatypes", I also look forward to being able to declare a data type within the language as part of the regular syntax when I need it. Also, I love the idea of replacing the -> operator with . to access object methods and properties, thus ensuring that the style is consistent with other OO languages.

I would love to hear what other Monks are thinking about this. What do you like? What do you hate? Personally, I think that this will be the best version of Perl yet. It may take a little getting used to but as long as it allows(nay - promotes) Impatience, Laziness, and Hubris, I will be happy.

I know that a lot of people are nervous about Perl 6, but they shouldn't be. Yeah, there is talk about co-routines, curried functions and things like that, but that's going to make the language more powerful. Interestingly, even though many features are going to be added to the language, it's going to be even easier to use.

Some things I like:

The variable prefix notation will be based on the variable type and not on the access method:

While this has not been nailed down, the first example above hints to the compiler that you will mostly be using integers in the array, so the compiler will optimize for it. However, you can stick the occassional string in there.

The second example tells the compiler that there will only be integers in the array. This will likely throw an exception (maybe at runtime?)

How about lexically scoped subroutines? Now, you'll be able to have truly private methods and ensure that they are only called as methods. No more letting people call methods as subroutines and getting things screwed up.

Access to your caller's lexically scoped variables through a MY pseudo-namespace. While I'm not sure about this, it does mean that you'll be able to do exports to your caller's lexical scope without globals. Yay :)

Parrot will be separate from Perl and we should have the ability to program directly in it for runtime benefits. In fact, if the work on byte-code compilers comes to pass, we'll be able to write Java applets in Perl. Look out Java, here we come :)

There's a lot more, but that's all I can think of off the top of my head and I need to get to work. The only real downside I see to Perl 6 is that it likely won't be out until late 2003 or 2004 :(

Programmers routinely get those wrong when they're first starting with Perl. Now they'll get them right.

I won't get it right (at least for a while). I bought into the whole idea that the prefix showed what variable type is being accessed (though it does get a little fuzzy when dealing with references). It may help new Perl programmers, though.

More compiler hints and optional strong typing! This is going to overcome one of the biggest objections to Perl!

And add one of my strongest objections to virtually every other language but Perl. I realize that it will be optional, but so (in theory, at least) is 'use strict'.

Actually, I'm looking forward to Perl 6. I've always hated the arrow syntax for Perl's object-oriented features, and I'm willing to give up the '.' concatenation operator to get rid of it. :-)

"I know that a lot of people are nervous about Perl 6, but they shouldn't be. ... The only real downside I see to Perl 6 is that it likely won't be out until late 2003 or 2004."

Because 13 years later, they still won't have to worry about it. Here we are in 2015. But why worry about when Perl 6 is going to finally someday be released? We have changed so much as an industry in the past 13 years. I myself have had ZERO need for the features that Perl 6 would have provided over this decade, instead I find the need for continuous delivery. Git, Jenkins, perlbrew, vagrant, AWS ... these are the tools of the future.

(Update: @seen{...} is now %seen{...}) So long as I can write %seen{@data} ^= 1 and @histogram[map /\d/, $n] ^++, I will be the happiest person alive. Those will be Perl idioms one will be hard-pressed to find in any other language. The hyper-operators are, I feel, long overdue, and should be received with much celebration. The loops required to mimic them in current versions of Perl will be optimized into the Perl core, which -- apart from sounding nifty -- is nifty.

Perl 6 is mainly about re-engineering our core processes and utilizing new paradigms for work efficiency and extending our empowerment to meet a wide spectrum of abilities.

Oh, sorry, I was reading "The Dilbert Principle". Where was I?

Perl 6 is about rethinking a lot that programmers want to do, but can't really, in Perl. The amount of "stuff" is measured by CPAN's growing number of Perl extension modules -- things like Switch and Attribute::Handlers and [insert favorite Damian module here].

But it's also about making the language more inviting to people from other backgrounds (which is a good reason to make the -> to . change) and to make a good enough impression that first-time callers become long-time supporters.

Anything I've found icky about Perl 6, I've taken with a grain of salt. Larry knows what he's doing, and one thing he's doing is listening to us. Another thing he's doing is milking the damned colon for all it's worth! STOP COLON EXPLOITATION NOW! But it will be for the best.

That's pretty much the way I feel. When I read the Apocalypses (I read them both before reading either Exegesis), I must admit I was almost disgusted. The one thing I've grown so very fond of in Perl is the relation between %hash, @hash{@list} and $hash{$scalar}. My world broke down when I read that this is going away.

But then, though I wasn't around then, I imagine that when people went from Perl 4 to Perl 5, they must have found themselves in an odd world too.

That is what I think it's going to be like to move from Perl 5 to Perl 6. Perl 6 will have its own idioms. We will all have to change the way we think and get accustomed to them. For what price? Well - I doubt anyone would nowadays say things were better, back in Perl 4, without all the newfangled stuff.

Perl 6 is going to have newfangled stuff as well - I predict that eventually we'll get used to it and will look down on Perl 5 as an inferior stepstone from the past, the same way we look down on Perl 4 now even if we remember it fondly.

The hyper operators are one of the things I also am every excited about. Part of Perl I immediately fell in love with is map and grep. Now come to think about them - aren't they are basically "poor man's hyper operators"? And guess what - we will have dinner with silver cutlery in the future.

You have an @ to designate "seen" as an array (Perl6 terminology, folks!, I know that's not correct for Perl5), but you're using the curlies for a hash. I am assuming that what you meant to do was use a hash slice of elements in @data and set all elements to 1 (true). If so, I believe that would be:

I've seen Larry's first draft of A4 and it's brilliant.
We're working through a few rough edges and that will
continue on Perl Whirl '02 next week. I'll write E4 on
the ship (no holidays for Perl serfs!) and the A4/E4 pair
should appear late Feb.

Re: Worry's about Larry and Damian muddling something fundamental

We worry about that too. But we have Nat Torkington, Jarrko Hietaniemi, Dan Sugalski, Simon Cozens, Hugo van der Sanden, and Jon Orwant on the design review team. Very few mistakes survive that calibre of scrutiny.

Then we have the entire Perl community giving us feedback on the decisions once they're made public. And we listen to that feedback very closely. Remember how the <> input operator was going to go away? Well, the outcry was so overwhelming (and so many good points made in its favour) that Larry reversed that decision.

The future of Perl is (collectively) in very safe hands.

Re: Scary changes in Perl 6

I have an article in the next Perl Journal (out next month) entitled "And Now For Something Completely Similar..." that illustrates that Perl 6 is going to be very much like Perl 5 for a large number of coders. And is going to feel entirely Perlish, even where it does differ from Perl 5.

I take five real-world programs (written by members of the Perl 6 design team) and port them to Perl 6. The gimmick is, of course, how little these typical (small) Perl programs actually change.

Actually, I'm not worried about that (especially, because of the reasons/people mentioned), I was just giving examples of thoughts that cross my mind while reading.

What I do watch for is some things for the simple-things-easy end of the see-saw over against all the furniture on the hard-things-easier end. &nbsp But putting in those sorts of shortcuts now certainly seems akin to premature optimization.

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

There are two things that I'm looking forward to about
the release of Perl 6.

The language itself. Hyper operators are bloody cool.
Scalar typing is going to be fun, too. Grouped file-test
operators, being N times easier to use, will probably
make my code N times safer. Ditto multiway comparisons.
I could go on, but you all get my point.

The small, subtle incompatibilities between Perl 5 and
Perl 6. I actually welcome these. They'll give me a
very good and difficult to ignore reason to go back
through my existing code and refactor it, or even rewrite
it from scratch. So my code will get better, because of
the review, and I'll have a relatively painless way to
get acclimatized to Perl 6 (since I've already done the
thinking to solve the problem, I'll be free to focus on
the language). I hope.

I guess I have most of the same thoughts others have. &nbsp I worry that Larry and Damian might overreach and get some really basic thing muddled. &nbsp I don't want to have to do $filehandle.autoflush(1) instead of $|++. &nbsp And '_' instead of '.' for concat?!

But then I was reading exegesis 3 and came to Damian saying "in perl5 that would be...". &nbsp I had a momentary sensation like accidentally coming on some Fortran code or something and thinking: "Boy, I remember when we had to go through all that just to get something done". &nbsp So, now I've stopped worrying (and I'm getting impatient with perl5).

(Maybe currying will transform Perl in perl6 like references did in perl5.)

Ugghhh! $++ doesn't do what you think. You think $| == 0 and that $|++ makes $|==1. Sure IFF $|==0. But what when some other fool does $|++. Then your $|++ doesn't do anything. Even worse $|-- doesns't set $|==0, because you blindly did $++. Now maybe your think this turns it into some sort of recursive lock type thing. No! because someone could have done $|=0 or $|=1 in another part or the code, cuz it's is the RightThing(tm).

I too have come to look forward to any forthcoming information about Perl6. I wonder when the next apocalypse/exegesis will be?

I'm excited to develop applications in Perl6 and compare how it feels to developing in Perl5. Will it be as fun? Could it be any more fun? I'm particulary excited about Perl6 because Perl is my first (and only well-grasped) programming language. Thus, my programming worldview is based in Perl5. Will Perl6 rock my world? Time will tell.

I was concerned about Perl6 but then I re-read the Apocalypes and Exeges.

Now I am trying to hold back my enthusiasm because I know it will be at least a year till there is something to use.

The things I like:
- Levels of competance/features. Like "use strict", but now for type checking and other stuff.
- Object everything (not cuz I am a OO lover, but extending hashes will new features like "freeze the keys of a hash in place" are easier.)
- try/throw/catch is great for network programs, errors are rare but they need to be caught; foo() or die; sucks after the first 300 repititions.- named and/or positional parameter declarations is going to be GREAT!. With some optional typeing, half my debugging code will disappear. And compile time errors, not just run time errors.

Things I am not so hot about:
- No explicit iterators, like my $iter := @a.iterator; $iter.getnext. What if I want to walk an array efficiently (ie no for(;;) loop) but be able to stop if one of the values requires immediate attention, then come back to the list. OR doing parallel operations on 3 or 4 or 200 arrays simulaneously.
However, iterators may be able to be constructed with continuations. The Parrot guys have stated the goal that they want to have continuation support in the VM.
- No mention of a standard Pre-Processor. I would like to have assert() and other simple macro expansions without haveing to take a runtime hit on production code.

On iterators, I have released Tie::Array::Iterable, which allows arrays created into such objects to be iterable with iterator objects. I expect that with Perl 6, the mechanism for making iterators may be easier than having to cooerce the array as I did here.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"It's not what you know, but knowing how to find it if you don't know that's important