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

[knight]

"I think you are stoooooopid; here's a 5Mb binary..."

The issue isn't intelligence, it's how much time administrators have available to wrestle with an installation process when they're busy doing fifty billion other things. Make the installation extremely simple (and reversible) and you increase the chances that someone will actually install and use the program. Greatly. Make it difficult to install, and you increase the chances that someone along the chain of command will decide that isn't worth the hassle.

If the customer can install it without caring that it's written in Perl, it certainly isn't going to increase the popularity of Perl - because the customer doesn't even know Perl is being used.

By this logic, C and C++ must be really, really unpopular. No customer installing an application written in those languages knows that C/C++ is being used, after all...

The ability to deliver atomic, easily-installed apps would increase the popularity of Perl among the people who write the apps, not the people who use them. If a developer with the freedom to do so is picking an implementation language for an app, and one language requires delivering a bundle of modules and maybe getting the installer to do some other hand-waving, and the other language has an easy, ready-made way to shrinkwrap and deliver the app, that fact could very well sway her away from Perl if the other (dis-)advantages of the respective languages balance each other out.

[Abigail]

Excuse me? What makes you think a binary program is easier to install than a text program? The claim wasn't that the installation of the program is easier (of course it isn't - it's still a program), the claim was that maintaining the installation of Perl is hard. And that's something I question. It's as hard as you want it to be.

By this logic, C and C++ must be really, really unpopular. No customer installing an application written in those languages knows that C/C++ is being used, after all...

Oh, I see! C is so popular because people insist of using programs written in C! That's it! Yeah, right. The popularity of C doesn't depend on the number of people installing programs because they are written in C.

The ability to deliver atomic, easily-installed apps would increase the popularity of Perl among the people who write the apps, not the people who use them.

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?

-- Abigail

[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.

[John M. Dlugosz]

The ability to deliver atomic, easily-installed apps would increase the popularity of Perl among the people who write the apps, not the people who use them. If a developer with the freedom to do so is picking an implementation language for an app, and one language requires delivering a bundle of modules and maybe getting the installer to do some other hand-waving, and the other language has an easy, ready-made way to shrinkwrap and deliver the app, that fact could very well sway her away from Perl if the other (dis-)advantages of the respective languages balance each other out.

Exactly. One case at work involved a complex installation that had a master installer that would run other parts. It would have been great to write that in Perl. But, how does one run a Perl program off a CD without "installing" it or the whole Perl system first? Even using a bundling system like PerlApp had a certain amount of risk involved. Instead, we wrote that piece in InstallShield, which easily makes a self-contained single runable file that can be simply run from the CD or other location, and is known to do that well. However, it turned into a terrible mess because the language isn't at all robust or suitable for larger programs. I wanted to use Perl because of Perl the language. I could not deliver a Perl solution because of Perl the system.

—John