Perl 6 development does not detract from Perl 5

| 5 Comments

A recent thread on use.perl.org brought up one of the worst myths of Perl 6: That Perl 6 is harming Perl 5.

Andrés N. Kievsky commented in a thread on use.perl.org

drop this insane perl 6 thing immediately. Give us good, stablethreading in perl 5 instead of self-hosting grammars in perl 6.

Later he said:

proper OO syntax, multithreading, better speed ... are major issues in perl 5 that should have priority over perl 6 work. You can't expect me to believe that the perl 6 team can't work on that.

There's so much misunderstanding here about how open source works, I'm going to ignore the ways that Perl 5 has benefited from the process of creating Perl 6.

The problem with Kievsky's assessment is that it assumes that:

  • contributors are finite
  • contributors are interchangeable
  • contributors can be directed.

All three are wrong.

First, there is a vast, unbounded talent pool. The set of people available to work on Perl 6 is not limited to those who would otherwise be working on Perl 5. It's not as if there's a box of people that cannot grow or be added to. There are many contributors who have joined the Perl 6 project without having ever worked on Perl 5. In this instance, Perl 6 has actually brought people into Perl under the Perl 6 banner.

Second, not everyone can work on the same parts of different projects. The tasks on Perl 6 may well be very different than the Perl 5 improvements that Kievsky would like to see. I have been contributing to Perl 5 for years, but I'm not at all available to help on the Perl 5 tasks he wants, because they're not in my area of expertise. However, I can help a lot with Perl 6 tasks, and not just programming. Parrot and Perl 6 are a better fit for me.

Finally, and most disturbing, Kievsky seems to think that by wanting something badly enough, people will work on those tasks. Unfortunately for this idea, there is no one directing Perl 5 development tasks, and nor can there be. Open source contributors are volunteers. They work on what they want to work on. Even if I was clamoring for those Perl 5 improvements, I'd rather keep a great programmer working in the Perl community working on Perl 6 rather than leaving Perl entirely because there was no work she felt like doing.

The only way to get a feature added to Perl 5, or any open source project, is to write it yourself, or to encourage others to work with you on it. It's the way of open source.

Perl 6 and Perl 5 development work are not mutually exclusive. Work will continue on Perl 5 long after Perl 6 has hit prime time.

5 Comments

Perl 6 has been very, very good for Perl 5. For example, Perl 6 was a major driver of the Perl testing revolution.

The whole thread is hilarious.

I'd say if Perl 6 has harmed anything in Perl 5, it's the fact that it's prevented Perl 5 from becoming Perl 6. The major version number being stuck at 5 for so long is bad marketing (and being stuck there permanently is worse). As an engineer, I know the numbers are meaningless, but as a human I also know they are not. Perl 5.6 could have been Perl 6, Perl 5.8 very easily could have been Perl 6, Perl 5.10 should have been Perl 6, Perl 5.12 really should become Perl 6. I think Perl 5 is going to continue for quite sometime after Perl 6, are we going to have Perl 5.14? Perl 5.16? That's bordering on ridiculous, from a marketing standpoint.

Perl 6 isn't even the same language anymore, it should be called Perlsbane or something elese. Perl 6 is tightly related to Perl 5, but it's still a different language. Don't get me wrong, I'm looking forward to Perl 6, but until there's a release, I'm a Perl 5 guy. Perl 6 is just a toy until then. I'm left with angst about the pending arrival in the meantime.

I think most the arguments go away within 6-12 months of the release of a real usable Perl 6 implementation. If Patrick and friends gets Rakudo working well enough to release something, I think these arguments will settle down quite a bit. Once we have at least one complete, usable, and stable implementation, the arguing will die away as people get on with their lives in the new order.

But anyone stuck in Perl 5 land maintaining the legacy products we're building today will probably be annoyed to work on Perl 5.18 instead of Perl 7.2.

Cheers.

Hi Andy!

I agree with your arguments - Perl 6 does not detract from Perl 5, and indeed it's not as if you can uniquely assign tasks to FOSS developers like that.

I'm reminded of similar arguments I've heard about why FOSS developers should not support Windows (some time before all hell broke loose after one KDE developer ranted about it on his blog.). One thing that was repeated was that a developer's spend on porting one's software to Windows, or making sure it runs there could be better spent on doing other stuff.

However, I don't micro-manage my time in such exactness, and I can gain many more potential users or co-developers who are using Windows, and I can cater for people or organisations who need to use several OSes (which was one of the main reasons why Subversion became more popular than GNU Arch, for which supporting Windows was not a priority), and I can also benefit from input by these users, and can also later convince to try more FOSS or even a completely open-source OS, etc. etc.

The official stance of the Free Software Foundation and the GNU project, is that as undesirable Windows and other non-free operating systesm are from their point-of-view, GNU software and other FOSS, should be ported to Windows if possible, and if there are willing contributors. (see for example cygwin, MinGW/MSYS, etc.) This is not different from porting GNU software to non-free UNIXes. Therefore, I don't think that advocating the prevention of porting free software for Windows complies with the ideology of most of the FOSS community, including some fanatic ones such as the FSF and GNU.

@andrew.sterling:

I'd say if Perl 6 has harmed anything in Perl 5, it's the fact that it's prevented Perl 5 from becoming Perl 6.

I agree with your comment, and have been feeling the same way for a long time. One suggestion I proposed in the "Critique of Where Perl 6 Is Heading" is to rename Perl 5 into something like "Fifer 1.0" or "Fifer 2.0" or whatever (though I admitted there I thought Fifer was a bad name). I originally planned a backwards compatible Perl 5-derived language called Rindolf with some relatively evolutionary improvements, but since "rindolf" has become my default IRC nick (out of virtue of being how one of my favourite AD&D characters were called), and while I have a big ego, it's not big enough for me to desire calling a language after me.

Of course, the exact choice of a name is not the most important part, but rather the fact that we should ditch the perl 5.12, 5.14, 5.16 ... up to 5.666 and beyond, and instead start with $Fifer 1.0 or $Fifer 6.0 or something.

Leave a comment

Job hunting for programmers


Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.