It’s the first session on Friday and I’m in Perl and Parrot: Baseless Myths and Startling Realities with Tim Bunce. As people were filtering in from the break, Tim displayed one of my favorite xkcd comics for us to enjoy.
There are so many holy wars debates about whether one language is better than another. Instead, the right question to ask is whether or not the developer’s skill set is right for the job. I agree. When I look for a developer, I’m more concerned with how they think than in what language they think.
Unfortunately, Tim is preaching to the converted in this talk. Nearly the entire attendance already uses Perl and don’t believe the myths. With that, let’s conquer them anyway.
Perl is Dead
No it isn’t. It’s two decades old and still growing strong. The books aren’t flying off the presses with great speed because the Perl community already has excellent books.
The trend when searching for “web development” jobs shows Perl growing very slowly in relation to other languages, particularly PHP. However, searching for “developer” jobs shows Perl growing very strongly and holding its own extremely well.
As a lurking member of the Perl community and an active member of my local Perl Mongers group, it’s been my experience that Perl programmers tend to be quite happy with their jobs. Which, unfortunately, has made it very difficult for me to find talent.
In fact, Perl is growing faster than ever. A simple look at how much work is going into CPAN will show that. The community is strong and Perl is everywhere.
Perl Is Hard to Read / Test / Maintain
Only if you’re doing it wrongly. We have Perl Best Practices, to use as the default documentation for coding standards, leaving developers with the need to only document when they deviate from the norm. There’s Perl::Tidy, to force any Perl code into one’s own personal style. Perl::Critic for ensuring that code is being well-written and follows best practices. And there’s no end to the Test::* modules and the work being done to make testing easy. There’s even a coverage analysis tool.
Perl 6 is Killing Perl 5
In fact, Perl 6 saved Perl 5, but one has to be close to the center of the community to see that. One should notice that Perl 5.8 and 5.10 have both been released in the time that Perl 6 has been in development.
There is a culture of testing around Perl. So many tests have been written for Perl 6, and the language is being defined by its test suite. This culture has leaked out to the community. In fact, I find there now exists a lot of peer pressure in the community to do proper testing.
Perl 6 Is Not Perl
Yes, and no. Unfortunately, I was so busy trying to catch up with the last section that I missed most of the points Tim made. In the end, I feel that this is fine. If Perl 6 was supposed to be Perl 5, why not just use the perfectly decent, already existing Perl 5? Which is still being actively developed.
Perl 6 Will Never Be Ready
It’s not on a schedule and, if it were on a schedule, it would be crap. It will be ready when it’s ready. Better to do it right than screw it up. The development model encourages a lot of experimentation, and it’s difficult to schedule experimentation.
There’s No Perl 6 Code
Sure there is. Thousands of lines of Perl 6 code exist in the test suite that came about from Pugs. These very same tests are being used in Perl 6 development today in the form of Rakudo, Perl 6 on Parrot.
The important thing to note is that Perl 6 refers to a specification. It does not refer to a particular implementation. Any implementation that passes the test suite may call itself Perl 6.
From an authority in the audience (who I don’t recognize, unfortunately), we have been told that there will be a useable Perl 6 by this Christmas. A round of applause ensued.
[tags]oscon, oscon08, oscon2008, Perl, Tim Bunce, myths[/tags]