Re: Re: The Future - Shipping Applications Written in Perl

[knight]

Could you please, please tell us what's so frigging hard in installing a program written in Perl that magically disappears when it's delivered in a binary format?

Modules. Dependencies between modules. CPAN.

Don't get me wrong: I love CPAN. CPAN is a fantastic resource, one of the most valuable things about Perl. And like just about everyone else, I heartily recommend that people writing a script look there before reinventing yet another wheel yet another time. But nothing comes free, and CPAN's bill comes due when you want to pass on your script to the rest of the world.

At a minimum, you have to list the modules that anyone wanting to use your script has to download from CPAN. If you used an API from a newer module, document which version is required. If one of your modules uses a newer API from some other module, document that. If there's no RPM version of the module, or ActiveState's prepackaged version doesn't work or install right (no joke; this was the case with one module I relied on), document that your "customers" will have to build their own--tough luck if you used a module that requires a C compilation step and they don't have one installed. And so on.

Now put yourself in the shoes of someone administering a network of, say, 200 workstations, who gets a request to install your cool script so all of the users can benefit from it. Some of the workstations were installed two years ago, some last year, some this year. Slightly different installation procedures each time, because requirements change. Different versions of the operating system, too, based on what was current when the workstations were purchased. You know some have custom stuff installed because certain users had specific requirements. And you don't even know what custom stuff is installed on some of them, because some savvy users had enough clout to get management permission to administer their workstation for themselves.

Throw in the fact that, even if you do already have Perl installed, a script that's already in use might get broken by an upgraded module because, occasionally, a module writer isn't careful about backwards-compatibility, or because a bug got by the module's tests. The last thing you want to have happen is to put your job on the line because you upgraded a module, weren't thorough in your testing, and broke some other crucial script that half of the network relies on...

The usual suggestions of ppm or perl -MCPAN -e shell for module installation don't scale real well in this sort of environment.

All of these hurdles can be overcome (especially given the fact that the administrators aren't "stoooooopid" :-), but overcoming each hurdle requires extra work. It takes extra time just to decide whether or not something is a hurdle that needs to be overcome (like running through the existing scripts to make sure they're not broken by a module upgrade). And each of these additional steps is a point at which something can go wrong. Each additional step becomes a point at which an administrator can say, "This is starting to be more trouble than it's worth," and drop the whole thing in favor of some non-Perl solution with which they're more familiar. (And then, of course, go off and swap war stories with the other administrators about what a pain in the *ss it was to try to install this Perl script on his network's workstations.)

We tend to think that the way to make Perl more popular is to just talk up the advantages, how flexible and productive it is, what a great resource CPAN is, etc., etc. But another crucial component of "selling" something is to find out what the "customer's" objections are, to take them seriously, and to find or provide solutions for them, one by one. The plain fact is that one of the objections the rest of the world has about Perl is the added time that module maintenance requires, especially in a traditional IT environment.

If Perl had a simple way to install shrink-wrapped scripts, it wouldn't make absolutely every installation problem magically disappear. But it would sidestep a really big one, and would settle, in Perl's favor, a lot of arguments over whether or not Perl is a cost-effective implementation language for delivering an application to a large user base.