Re^3: Production Perl6 in early 2010?

[moritz]

It's not wrong, but very misleading.

The announcement of the parrot road map has nothing to do with the release date of Perl 6 (which by itself isn't well defined - do you mean the language specification? or the first implementation?).

"production parrot" does not imply "production rakudo".

If you link to one thing and ask a completely different question at the same time, one could suspect that you think the two are related, which is why I answered to clean up any possible confusion.

Most people couldn't care less about obscure project names vs. what language they implement.

If you count all people in the world, yes. If you count Perl programmers, no.

Most Perl programmers are interested in parrot because it started off as a platform for implementing Perl 6, not because it's in general a very cool project. So for them it does matter to know that a production parrot doesn't imply production Perl 6.

As for the "obscure project names" - most people are more confused if different things have the same name. Now different things (language, compiler, vm, test suite) have different names, which I find not confusing at all. I don't care if you call them "obscure", I can remember them and type them without my fingers, so I'm fine with them.

[assemble]

I see. I kind of figured if you had production parrot it would imply production rakudo. I guess I was wrong. I do see your point on why that needs clarified.

But I don't see your point on why it is good to call the different parts completely different names. I'm fine with calling things the "Perl compiler", "Perl interpreter" or "Perl VM". It's the same naming method as every other language I know. When you run it with just one command it really doesn't make sense. Right now, I type perl somescript.pl and I only deal with one program.

I'll admit that I haven't kept up well with Perl 6, but I'd be surprised, and somewhat disappointed, if it's any harder to use than rakudo somescript.pl or whatever the program I see eventually winds up being called. I didn't think we would have to do something like perlc stuff.pl; perl stuff

So yes, they are different pieces and can't be talked about the same, and that makes sense. But in the end it'll all be Perl6.

[moritz]

But I don't see your point on why it is good to call the different parts completely different names. I'm fine with calling things the "Perl compiler", "Perl interpreter" or "Perl VM".

That was fine for Perl 5, where the language was defined by the compiler/interpreter, and there wasn't any chance to ever have a competing compiler/interpreter.

For Perl 6 that's different. The language is defined by a bunch of text documents describing the language, and a test suite that is becoming the code representation of that specification.

There are multiple Perl 6 compilers in the works (namely pugs, Rakudo, Elf, mildew + smop), and calling them all just "Perl 6 compiler" would be very confusing.

If you like the analogy, there's also not "the C compiler", but various of those (GCC, MSVC, Borland, Intel's s C compiler, Sun's C compiler, TCC, ...)

For parrot it's a bit different: its purpose is to serve as a virtual machine for multiple languages (Perl 6, Lua, TCL and Ruby, to name just the most active or advanced compilers targeting parrot), so it wouldn't do the project justices to call it "the Perl VM".

But in the end it'll all be Perl6.

In the end Perl 6 will be Perl 6. Nothing more, and nothing less.