Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

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

by helgi (Hermit)
on Apr 26, 2004 at 13:30 UTC ( #348169=note: print w/replies, xml ) Need Help??

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

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?

Helgi Briem
hbriem AT simnet DOT is

Replies are listed 'Best First'.
Re: Re: Re: What is Perl *NOT* good at
by blue_cowdawg (Monsignor) on Apr 26, 2004 at 13:37 UTC

        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.

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


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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://348169]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (2)
As of 2018-04-20 07:55 GMT
Find Nodes?
    Voting Booth?