LWN.net Logo

A Perl 6 status update

A Perl 6 status update

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

Nobody's forcing you to use Perl 6 if you don't like it.

I agree. The problem is that Perl 6 takes developer brainpower away from Perl 5. Splitting up the development effort like that is not a good idea. If Perl 6 is so completely different from Perl 5, then it should be called something else so end-users and developers are clearly aware that it's a totally separate project.

I'm not even going to bother to respond to the rest of your childish post.


(Log in to post comments)

A Perl 6 status update

Posted Dec 31, 2007 20:22 UTC (Mon) by chromatic (guest, #26207) [Link]

The problem is that Perl 6 takes developer brainpower away from Perl 5.

Is that a feeling or a fact? If you're going to present it as a fact, I'd like to see some evidence for that, perhaps backed up by statistics and interviews with a wide range of Perl 5 and Perl 6 developers.

We can start with the fact that both Larry and I have hacked on both Perl 5 and Perl 6 in the past couple of years, often simultaneously. It's also a fact that Perl 5 has had several new developers offer patches in the past few years, and so have Perl 6 and Perl 6-related projects. Would we have devoted the same amount of energy to either project if the other did not exist? Unprovable.

Another good fact is that several features of Perl 6 have made their way into Perl 5, mostly not written by Perl 6 developers. I don't know what this proves either, but I'm not sure it supports your factpinion.

If Perl 6 is so completely different from Perl 5, then it should be called something else so end-users and developers are clearly aware that it's a totally separate project.

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

A Perl 6 status update

Posted Dec 31, 2007 21:55 UTC (Mon) by dskoll (subscriber, #1630) [Link]

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.

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.

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

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds