Re: Re: What is Perl *NOT* good at

[helgi]

What's wrong with GUI programming in Perl/Tk? It's not as good as Delphi, but sure beats hell out of Java.

What's wrong with PPM? It has always worked perfectly for me. No complaints at all in 3 years of heavy use.

What are your "Shipping" problems? What can be easier than shipping a Perl app? It is plain text after all?

[blue_cowdawg]

What are your "Shipping" problems?

Well... just to be "devil's advocate" I'll bite on that one. Just in my own little world at work I have troubles "shipping" code from one machine to another. Quite often code that I develop and test very thoroughly on one machine explodes due to missing modules on another machine depending on wheather or not the admins on the target machine have been diligent in keeping their CPAN module list up to date.

While I have developed standards for what belongs on machines, what version of Perl to install, etc. etc. some folks just don't listen until there's a probelm.

[Abigail-II]

That "shipping" problem you describe is not at all Perl specific. It's a common problem, especially with open source software (commercial software more often comes with "everything you need"). Tons of software on Linux won't run the first time you install it, because it uses some library (and often, a particular version of that library) you don't have installed. Python applications won't run if the libraries they depend on aren't installed. Etc, etc.

The fix is language agnostic: just ship everything you need. (That's how many admins want it anyway: they prefer not to have to maintain a set of libraries/modules with the risk that if one application needs an upgrade of a module, a dozen others cease to work).

Abigail

[blue_cowdawg]

That "shipping" problem you describe is not at all Perl specific.

I wholeheartedly agree, Abigail. And I would further submit that this issue is not confined to Open Source softare either. Such issues also occur with closed source or commercial softwere where the vendor is dependant you your having third party software installed as well as their own. For instance code that is dependant on one version or another of the Sun JDK such as for Java servlet engines.

The fix is language agnostic: just ship everything you need.

Which for some most cases works just fine. To make matters worse are compatability issues you can run into. For instance I remember a commercial package that would only work with an very ancient version of Perl. And it expected that version to be in /usr/bin/perl. If it had been scripts only that were the issue I could have munged that, but NO! they had embed it in there C code as something like

       exec ("/usr/bin/perl",@ARGS);

to kick off their scripts.

Thankfully their product was replaced by someone else's product...