2005 has seen a lot of discussion on the future of Perl (both 5 and 6) and in particular the fact that Perl's "market share" being assaulted from a number of directions.
Perl is still the "second language" of the world. "Perl" job searches are practically ruined by all the "... and Perl" entries. It is still the duct tape and the Swiss Army chainsaw. As Linux/BSD and Open Source grows, so does its role here. CPAN continues to make this a hard role to assault quickly.
Perl dominates BioInformatics. And I'm seeing some evidence that Perl is leaching out from the specific BioInformatics projects to handle other projects in biotech companies, pushed along by CPAN's ability to talk to everything. This even seems to be happening in cases where companies are 100% Windows.
Perl does respectably but is no longer dominant in general web development, and is doing quite well for large-scale web development. (mod_perl etc)
PHP has largely wiped us out for entry-level and casual web sites, particularly where there's no need for significant backend offline processing and the web _is_ the application.
Python occupies a somewhat strange position as a general scripting/development language, with some web and some systems stuff. It continues to slowly grow but until they get their act together on a "real" CPAN I'm not too worried.
Ruby is the new kid, and although I've yet to see a job ad anywhere for it here in AU, it's specifically targetting the easy-to-learn niche for scripting and web as well.
What can we learn from this? Well in particular I think we can learn a lot from PHP. This ugly, often insecure, cludge of a language has almost nothing technical going for it. But it has one HUGE positive in it's favour.
It's REALLY easy to install. The PHP people have made sure it comes standard, or installs easily on pretty much all platforms, and to use it you just rename a
PHP is to web development what Debian's apt-get install program is to system administration.
Ruby on Rails is somewhat the same way. All that magic introspection makes it very approachable.
While I'm not yet convinced Ruby on Rails is useful for "real" serious work, it is definitely a worthy successor to any tasks people might otherwise do in PHP
Because most people try new things only when they need to, it is important that that first hour is as smooth as possible. After that, if they can get what they need to do done easily, they'll stick with you. PHP hit a hole in one in that regard. At this point, I can't see any other possible answer to why PHP is a success
And so I'd like to define Elaine's Law.
"Just make it easy to install, stupid!"
You should insert expletives as you see fit at appropriate locations when using Elaine's Law.
Elaine's Law is named after Elaine Hietaniemi Ashton (also known as aevil or happyfunball on IRC) who tried to get people to understand this years ago, until she got sick of being ignored and sodded off to Finland with Jarkko.
She hammered the point into me on a half dozen occasions, at a time when I haven't seen a similar attitude from others in the Perl community.
So consider Elaine's Law next time you catch yourself saying "It's easy, just follow the 5 steps in the README file after you unzip the tarball" to a newbie. Think again and do it better. Automate as much as you can, offer a default auto-discovered configuration if you can, verify any install variables you need from the user properly and in a user-friendly manner. Hell, go all the way and make the installer conversational and talk to the user like a person.
Just make it easy to install, stupid!
You have to install modules via their "blessed" precompiled mirror of CPAN, which as I speak is a long way behind CPAN and with critical dependency issues that mean a third of the modules are broken and won't get any newer. They are improving things, but it's still not like having the full CPAN in all it's glory. Just running perl -de 1 from the command line throws errors...
PXPerl looks like being a suitable successor to ActivePerl. It seems to install cleanly, bundles some of the most notoriously hard to install modules already, and the next release will also bundle and preconfigure a compiler, so that you should be able to install compiled modules directly from the vanilla install.
Or so I hope. But the author seems keen, and that's half the solution.
Because of the sheer richness and variety of CPAN, I suspect Perl is poised to really move strongly into the VBA space, as soon as we can get a Windows install of Perl that both follows Elaine's Law and integrates with the native CPAN correctly.
It lets us leverage our killer app, the CPAN, to move into another area. Let us not shun the Win32 programmer, because in a few years they are going to be Linux or OS X programmers too.
And the last thing we want is a reputation of being hard to install. Because for most people, hard to install means hard to use. And with a language as rich as Perl, that can be the kiss of death right there.