A Perl 6 status update [LWN.net]

A Perl 6 status update

Posted Dec 31, 2007 21:55 UTC (Mon) by dskoll (subscriber, #1630)
In reply to: A Perl 6 status update by chromatic
Parent article: A Perl 6 status update

The creator of the project gets to name it, and he's happy with the difference being the version number.

Well, good for the creator, but bad for the rest of us. Having to completely-different languages given the same name is going to cause harm. For example: We ship a large commercial project written mostly in Perl 5. When (if?) Perl 6 is ever released, we have two unpalatable choices:

Waste time porting our software to Perl 6 and making sure it runs correctly. I call this a waste of time because it is! Our software runs fine on Perl 5.
Take endless support calls from confused customers who wonder why their version of Perl won't run our software.

If Perl 6 were called something else (I dunno, maybe Parrotugs or something) there'd be no problem. Our software requires Perl. If you also want to use Parrotugs for something else, great!

I'm also the maintainer of a couple of CPAN modules (MIME::Tools being the most prominent) and if Perl 6 were called something else, I wouldn't have to port MIME::Tools (which is after all a Perl module.) As it is now, if I want to maintain the module, I'm going to owe it to the audience to port it to Perl 6. This is work I don't really need, thanks!

All in all, Perl 6 really looks to me like a failed IT project. Lots of vapour, people running in lots of different directions, and very little actual working code. It frankly scares me.

(Log in to post comments)

A Perl 6 status update

Posted Jan 1, 2008 0:24 UTC (Tue) by chromatic (guest, #26207) [Link]

I'm having trouble figuring out how you've never ever had dependency "trouble" with any other dependency. If you really need to control the entire stack your customers use, have you considered shipping the entire stack yourself?

(That presumes that Perl 5 code won't run on Parrot in process with Perl 6 code, and the plan is to make that possible. That's why we're writing Parrot.)

Are you going to remove tmp_recycling() again and rename MIME::Parser, by the way?

A Perl 6 status update

Posted Jan 1, 2008 11:29 UTC (Tue) by dskoll (subscriber, #1630) [Link]

I'm having trouble figuring out how you've never ever had dependency "trouble" with any other dependency.

We depend only on core Perl modules. We ship a sizeable number of CPAN modules to make sure our dependencies are met, but it's by no means the entire Perl environment.

Are you going to remove tmp_recycling() again and rename MIME::Parser, by the way?

Well, since tmp_recycling has never actually done anything in the entire history of MIME::Tools as far as I can see, probably it will go away! (You can blame my co-maintainer for removing it originally...)

I'm not sure what you mean by renaming MIME::Parser.

A Perl 6 status update

Posted Jan 1, 2008 10:51 UTC (Tue) by epa (subscriber, #39769) [Link]

The same argument applies for the transition from Perl 4 to Perl 5.  Most intelligent people
understand the idea of version numbers.

A Perl 6 status update

Posted Jan 1, 2008 16:01 UTC (Tue) by dskoll (subscriber, #1630) [Link]

The same argument applies for the transition from Perl 4 to Perl 5.

Well, there are a few differences:

Everyone was clear that Perl 5 was the successor to Perl 4, and not a "completely different" language as some have claimed here.
A small number of developers sat down in 1993 to develop Perl 5 and cranked out a finished product in under two years. They didn't turn it into a potentially decade-long research project full of experimental (even pie-in-the-sky) development.
Perl 5 introduced features required for modern programming like my variables. So it was obvious that it made sense to move from Perl 4 to Perl 5. The 5 to 6 transition is less obvious; there are some nice ideas in Perl 6 but nothing as compelling as the 4 to 5 transition.

A Perl 6 status update

Posted Jan 2, 2008 2:52 UTC (Wed) by rloomans (guest, #759) [Link]

Having to completely-different languages given the same name is going to cause harm.

I doubt it. If you read: http://dev.perl.org/perl6/doc/design/syn/S01.html

You will see that not only is backward compatibility very important, interoperability between Perl 5 and 6 code - even in the same file - is very high on the list.

As I understand it, Perl 5 modules will be perfectly usable from Perl 6 code. The only incentive for using Perl 6 syntax will be if you need it's features. If you don't, don't re-write. Simple.

As it is now, if I want to maintain the module, I'm going to owe it to the audience to port it to Perl 6. This is work I don't really need, thanks!

I think that you are exaggerating.... Once Perl 6 is deployed you may have reason to complain if there are compatibility issues.

As I understand it, your concerns are ones that are very high on the list of the Perl developers' priorites.

Please damp the flames a bit.