An (improved) argument for a bottom-up approach to boosting Perl...

A bottom-up approach does not directly address the issue at hand, Perl's reputation among important decision-makers. But as an indirect factor it may be more effective than the top-down buzz of a "Perl Inside" marketing campaign.

The popularity of PHP, for example, was built from scratch on bottom-up buzz. It had so little hope of ever being widely used that its creator named it "Personal Home Pages". But it caught fire for two reasons: 1) it's friendly to newbies, and 2) it's web-centric. (And hosting providers supported it, as Ben pointed out). When you've got a lot of wide-eyed, excited newbies giggling over their first sticky widget, you might not have much talent but you've got tons of buzz. When you also consider that the World Wide Web was simultaneously the subject and medium of this buzz, it becomes hyper-buzz. The newbies turned into real programmers, started real business and made real money. And now PHP is taken seriously by the PHB in the corner office. No one had to advertise PHP. The environment was simply saturated with buzz about it.

How can Perl get buzz? Get newbies. This won't help Perl in the short run, but it will be vital in the long run to breed a new generation of Perl hackers, and could provide a solid boost to Perl's reputation within a few years. How can Perl get newbies? Others have pointed out that Perl is not the typical "academic" language. That's why I would propose targeting not the CS students but the vast superset of computer users. Realistically, only a small portion would be interested in evolving into power users. But for this portion (still huge in absolute terms), the ubiquitous utility of Perl is only a few lessons away.

So here's a few carrots for those kids:

1. Make Perl easier to find. The Unix core of Mac OS X is a HUGE opportunity for Perl to be introduced to a new, and growing, community of users. But most Mac users ignore the Terminal, even those with the aptitude to quickly learn how to use it. A free light-weight Cocoa wrapper around Perl could tip the balance. Rather than a full-blown IDE, it would be a text editor that mediated the input, execution and output of the script, changed mode transparently, etc.

2. Make Perl easier to learn. In terms of utility and usability, php.net outshines any perl reference site. By a lot. Even without the type of GUI proposed above, a high-quality online Perl reference would help.

3. Make Perl CGI easier to use. The aid of "CGI::Carp qw(fatalsToBrowser)" should be built-in and ON by default. (How hard is it for perl to figure out that it was called in a CGI context and prepend a header upon expiring? For that matter, how hard is it for Apache to do?) "500 Server Error" is NOT helpful. Sure, you could check the error log. But some ISPs don't even allow access to the error log. When you're smart enough to turn it OFF, you'll be smart enough to turn it OFF.

4. Make Perl fun. Celebrate the elements of sport and humor latent in Perl (or Perl hackers, anyway). Perl puzzles. Perl duels. The Obfuscated Perl Contest is a great example.

5. Clean up CPAN. The egalitarian nature of CPAN is commendable. However, quality and activity vary widely and redundancy is rampant. A little moderation could tidy it up a bit without ruffling too many feathers. How about a distinction for the most downloaded modules in each class? Sort by number.

6. Add features. PHP is certainly obese, but Perl never pretended to be a Spartan, either. How about pulling some of the most widely used and most stable module features into the perl executable? PHP has a major convenience edge over Perl. When you're a newbie, convenience trumps performance. Perhaps some of these new features could be flagged at compilation.

-Bogart


_______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm

Reply via email to