Perl 6 on Parrot is now known as Rakudo Perl

Breaking Perl 6 up into a specification and an implementation is all well thought-out and stuff, but seriously this will not "reduce some confusion" - it will introduce even more confusion. Not having a default (reference) implementation of the Perl 6 specification which IMHO _must_ simply be called "Perl 6" will make it even harder to bring Perl 6 to the masses. Furthermore, Rakudo doesn't sound like a "language" (sorry, I meant "implementation of a language specification") I want to write my apps in. IMHO, the Perl 6 development is still not paying enough attention to the marketability of our beloved language :(

Tobias, I totally agree with you. there should have been a default "implementation" called simply perl (perl 6) which is based on perl 5 and has full traceability with it, and then the rest of the implementations, not based on perl 5, can have their unique names (pugs, etc.)

Thanks for the comments. I'm working on a Q&A sort of document to explain these things.

First, you can call them Rakudo Perl and Pugs Perl if you like. Those are fine.

There is no reference implementation of Perl 6 any more than there is a reference implementation of C or FORTRAN.

Multiple implementations is very common. GCC may be a commonly used C compiler (and FORTRAN compiler and...) but it's not the only one, nor is it the reference implementation. You have MS Visual C and Turbo C and Intel's C compiler and all these different compilers and toolsets all implementing the same C language. Perl 6 is like that.

I don't understand djlvz means by "based on perl 5" for his vision of a Perl 6 reference implementation.

From what I've read the Perl 5 core has become somewhat difficult to extend over the years, thus I believe the fresh start for Perl 6 was a good thing. I also really dig the idea of having a VM (Parrot) for dynamic languages. But giving "Perl 6" some other name than "Perl 6" just doesn't help the difficult situation in which Perl as a language is in. Here in Germany it is dying quicker than many of you want to admit. Almost every company using Perl for serious web development already has or is in the process of switching to some other language (Perl will always have its place in system administration, "glue-code" and tools though). A working Perl 6 implementation 4 years ago (which could now be ported bit by bit to Parrot) could have saved Perl a lot of trouble. Unfortunately there's still no time machine to change things (and I think a lot of the Perl 6 developers would still argue that nothing is wrong and everything went well). Don't get me wrong: You're all doing an incredible job, but please don't invent even more names for Perl 6!

I like this move. Having a (somewhat) unique handle on this thing will help. At the SPUG meeting this week, particle was talking about the new parrot release and some perl6 stuff. Inevitably, someone would ask, "Perl 6 on Parrot or that PUGS thing?" I like the name. And I like the idea that the name could stand apart from its lineage a little bit. Perl lovers will think of Rakudo as the Perl (if they want). But, also, maybe people who don't yet love Perl (and maybe think of it as that cryptic, write-once language from the dark ages of Internet) will be introduced and fall in love with Rakudo without necessarily knowing its history. We don't have to beat people over the head with Rakudo's history and family tree. There's no reason that it shouldn't stand alone for those who just want a great language for getting things done.

@Tobias:

Perl 6 is still Perl 6 the same way C is still C even when compiled by any of the compilers Andy mentioned. In the same way, a bananna is a bananna whether it's eaten by a person or a gorilla (okay, maybe that's a stretch). I guess I just don't find that distinction confusing.

Also, as I understand from previous discussions about the "slow" speed of Perl 6 development, the pace has less to do slow implementation and more to do with allowing the language itself -- the specification -- an incubation period where it is allowed and expected to change and mature. Yes, Perl 6 has been a long time coming, but when it does arrive I believe we'll see significant benefit from that incubation, and Perl 5 has already seen benefit from the work.

Tobias: i think you're missing something. perhaps you should read the docs for Rakudo Perl 6 (here's the README.) when you run Rakudo Perl 6, it's called 'perl6'. in fact, you can build and run an executable based on parrot today. it will have the same look and feel of any other Perl 6 implementation, because that look and feel is part of the Perl 6 Specification.

think of "Rakudo" as a brand. have you heard of ActiveState ActivePerl? Vanilla Perl? Strawberry Perl? these are all brands of Perl 5. Rakudo, Pugs, and other perhaps lesser-known implementations (kp6, smop) are brands, too. they'll all look and feel the same.

Valid point, Andy! But I believe that people expect the next Perl to be called "Perl 6" (right down to typing: perl6 myapp.pl on the commandline). I'm not talking about those that follow the Perl 6 development process to be able to tell things apart (Parrot, Perl 6, Rikola ... ehm ... Rakudo ... Heck, I can't even memorize the name :)) I mean average developers and business people who want to know if Perl is still worth building a medium- to large-scale application with. Of course, it's not very elegant to have the same name for a specification and its implementation, but if we start confusing people with more names they don't expect, things are going to get more difficult for Perl's future than they have to be.

GCC has the word "C" in it. "Rakudo" does not have the word "perl6" in it. It's also pretty different because C is a compiled language, so the binary ends up being named whatever the program itself is named, and you never do "gcc binary" to run it. However, in an interpreted language, even with the #!, you often do "perl somescript.pl" (particularly in Windows). This may all seem simple and sensible now, but after we've explained it 10,000 times and 5,000 managers have said, "Yeah, but it's not Perl so we won't use it," it may seem less simple. In essence, the media outlets of the world and the casual users will probably look upon it as a new language without any of Perl's history, simply because it has a new name that doesn't even contain the letter P. Now, that could actually be a good thing, so maybe it's a good move. -Max

"[...] there should have been a default "implementation" called simply perl (perl 6) which is based on perl 5 and has full traceability with it [...]"

When I first started as Perl 6 compiler pumpking in 2004, there was an embryonic implementation of Perl 6 that was based on Perl 5. At that time the design team (Larry, Damian, Allison) advised me that we should probably abandon that effort and start over in Parrot. I figured that if anyone would know the best course of action, these folks would, and so that's what we've done.

So, we did start out with building Perl 6 on Perl 5, but decided that wasn't going to work out well, and switched to a different tack.

IIUC, KindaPerl6 is targeting Perl 5 as a backend, and so that might be one possibility. But even there the intent is not to build Perl 6 on top of Perl 5.

Pm

Max wrote:

GCC has the word "C" in it. "Rakudo" does not have the word "perl6" in it.

Correct, that's why we're calling it "Rakudo Perl", and just using "Rakudo" as a convenient shorthand.

By way of comparison "Linux" has the same sort of setup. There's no reference implementation of Linux. Instead we have "Ubuntu", "Debian", "SUSE", "Red Hat", etc., and people understand that.

Pm

Correct, that's why we're calling it "Rakudo Perl", and just using "Rakudo" as a convenient shorthand.

Ah, okay. :-) I have no problem with that. :-) And yeah, I totally agree about the Linux point--that's a good point. -Max

So, if I'm understanding this correctly, there'll never be _a_ main/official/reference/what 80%-of-the-users-will-want "Perl 6" but several "Perl 6" implementations. I always thought that Perl on Parrot (Rakudo) would be the Perl 6 most users would want, then why not label it as such? To be honest, I don't see how this will help Perl 6 (re)gain popularity. What's wrong with calling the specification "the Perl 6 language specification" and this Rakudo Perl thing "Perl 6". A lot of people in the corporate world criticize Perl for its "There's more than one way to do it" approach (I don't take sides here). Now with Perl 6 there's going to be "more than one implementation to use Perl 6". I doubt this will help the language but then again ... what do I know? :)

@Tobias: I understand exactly what you're saying, and I have the same concerns. However, there will not be a Standard Perl 6. There may become a de facto default Perl 6 because that's how it works out, but you can't declare a de facto standard.

Larry is clear that he wants Perl 6 implementations to be distinct from the specification. I think it makes a lot of sense to do that. Some people don't like TMTOWTDI, but then those people probably shouldn't be using Perl. TMTOWTDI is very much in Perl's blood.

Also, it's mentioned in my journal post but perhaps isn't clear here: Even though we're now calling the Parrot implementation "Rakudo Perl", it will still be invoked by /usr/bin/perl or /usr/bin/perl6 on the command line and in shebang lines.

Pm

I agree with Tobias. Perl 6 is an __endless__ writing of specifications. NO FREEZE to appear. Perl 6 is an __endless__ writing of implementation, due to __no__ final specification. NO FREEZE to appear. But Perl 6 has a bunch of fuzzy names. Welcome Rakudo Perl! All of them suck! imho. Monks, Tim Toady is not my friend in meetings with our CTOs! Monks, they bet on Java, worst on Ruby et.al.. Perl 6 is dead on arrival, nail 666 on the gravesone. My deepest sympathy, pietzke

I'll admit that I really haven't been following Perl 6 (sorry Patrick), but the comments above cleared up some stuff for me. As I understand it, Perl 6 is Perl 6, no matter whether you're using Pugs, Parrot, or whatever (you don't write Rakudo Perl 6 code, or Pugs Perl 6 code, you write Perl 6 code). To compile and run Perl 6 code, you can use Pugs, Parrot, etc. Parrot (as I'm sure is true with some of the others) is not specific to Perl 6. Parrot can also (will also?) be used to compile and run Python, PHP, Ruby, etc.

It comes down to what you'll be using to run Perl 6, no? Personally, I don't care if I have to type 'croc helloperl6.pl', so long as the code I write is Perl. :-) Am I understanding it correctly?

Jeremy, you have it. Perl 6 is the language. You can run a program on the Perl 6 interpreter by typing "perl6" at your command line, if you happen to have Rakudo Perl installed. Alternatively, you can run a Perl 6 program by typing "pugs" if you have Pugs installed. Or there's the other one whose name I keep forgetting.

(Similarly, you can run a Haskell program using "ghc" or "hugs" or "nhc98" or "yhc" or "hbi" or "hbc". And the results are exactly the same! The only difference is that one of the Perl 6 implementations will actually be called "perl6" - but just to keep people on their toes, its codename will be Rakudo Perl.)

If Haskell is too far out for you, think "java" versus "kaffe". Your application still runs.

Or even better, think "XFree86" versus "Xorg". Run "X" and the right thing will happen. You won't even need to care what's running underneath.

But please don't use "croc" however, since that's the name of a language I designed a few years ago. Maybe now I can use the Parrot runtime to finally implement it, since it's so damned easy to implement languages in Parrot... :)

Heh, wow I just pulled 'croc' out of the air. I was thinking about crocodile. :-)

I agree with Tobias. Perl 6 is an __endless__ writing of specifications. NO FREEZE to appear. Perl 6 is an __endless__ writing of implementation, due to __no__ final specification.

I respectfully disagree. The reason we don't have a completed implementation is not due to "an endless writing of specification". Put another way, assuming that the Perl 6 specification had been frozen a couple of years ago, I don't think we'd be any farther along towards an implementation than we are now.

In fact, I'd even go so far as to say that we'd be less far along with a specification freeze, because many (most?) of the specification changes that have occurred in the past couple of years have been made in response to issues discovered during implementation. This is true for both Pugs and Rakudo Perl. If the specification were frozen, we'd have a much harder time with implementation.

From my perspective, the time we've taken to build a Perl 6 implementation is due primarily to having some very ambitious goals, and because we've needed time to build the tools that could support Perl 6. But it's not because the specification itself is evolving.

Pm