in reply to Re: Re: What is Perl *NOT* good at
in thread What is Perl *NOT* good at?

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.

Replies are listed 'Best First'.
Re: What is Perl *NOT* good at
by Abigail-II (Bishop) on Apr 26, 2004 at 14:29 UTC
    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

[reply]

          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);

      [download]
      to kick off their scripts.

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

[reply]
[d/l]

In Section Seekers of Perl Wisdom