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 .html file to .php and add a tag. Done. Want to talk to a database? The simplest if equally ugly database MySQL has bindings in the language core.
PHP is to web development what Debian's apt-get install program is to system administration.
Instant gratification!
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!
A great example of this is to compare ActivePerl to the new PXPerl. With all due respect to ActiveState for supporting Perl, I personally find the integration of ActivePerl and CPAN horrendous.
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.
Let us not shun the Win32 programmer...
I'd disagree that the installation is poor with ActivePerl, as you can run 'ppm' and 'cpan' pretty much from the off. Admittedly you are relying on a largely non-current repository away from CPAN, but it is a start. Having a reliable codebase from which you can install from is the key part. There are several of us who program on Windows and have to either patch CPAN modules ourselves, try alternatives or rewrite the code. I'd rather see more effort being put into portable code than worrying about whether ActiveState's repository is out of date.
Once upon a time Perl could claim to be one of the most portable languages. These days it seems some CPAN distributions come with a huge caveat; works on Unix like OSs, and might possibly work on others (if you're lucky). To a degree I wonder if there is a bit of elitism going on. When I get the chance, I do try and write bug reports (with patches) in RT for various distributions. The ones I'm concentrating at the moment are those that are dependencies of others. There is one author that has an outstanding fix (not by me) on RT, that means I can't test (never mind install) nearly 100 modules from CPAN. Is it any wonder why ActiveState's repository is so far behind? There about 20 distributions that are holding up a good portion of my testing on Perl 5.6.1 on Windows.
My talk, 'Preparing For CPAN', was actually written because of the number of portability issues I found during CPAN testing. Richard Clamp thinks I should name and shame some of the authors, but I'd rather that everyone just thinks a little more carefully before uploading to CPAN. And yes I know it's all volunteer based, but when people are even supplying patches, they are trying to help.
Re:Win32
chromatic on 2005-11-20T07:23:10
Is it any wonder why ActiveState's repository is so far behind?Considering the number of bug reports they've sent for my modules... no. I'd love to have more feedback.
Re:Win32
barbie on 2005-11-20T09:20:45
That's a fair point. I wish they did send their reports. Although at least they are available online, just about.
In several cases there are CPAN Testers reports that match the test problems ActiveState have. However, looking at the reports generated for your modules I noticed many of the problems are missing because of the way Module::Build tests are not currently passed back to CPANPLUS. This is someting that is being looked at.
Re:Win32
Alias on 2005-11-20T12:50:20
It's the centrally run largely outdated non-CPAN repository that causes much of the problem. Instead of working out how to get a proper compiler working inside a default install of a Windows version of Perl, we have what is an enourmous workaround.
Is PXPerl does nothing else but solve the nmake/compiler problem on Win32, it will be a huge success, and we can look at dealing with module-problems from there (and be able to actually test things outself).
