|
in reply to Re^2: $^W or require warnings and import warnings;
in thread $^W or require warnings and import warnings;
I understand about having to keep a legacy perl around to support older apps, etc, and I don't have a problem with that. It just seems like a no-brainer to also have an additional up-to-date perl (i.e. a separate install) if you plan on using up-to-date scripts. Chances are very good that these new scripts weren't actually designed or tested on your legacy perl (i.e. you'll need to test/examine them). Having a separate perl seems a lot easier to me than examining every new script you put on the machine to make sure it's going to work with your legacy perl.
|
Re^4: $^W or require warnings and import warnings;
by duff (Parson) on Jun 16, 2005 at 14:42 UTC
|
Having a separate perl seems a lot easier to me than examining every new script you put on the machine to make sure it's going to work with your legacy perl.
Sure ... if you're even allowed to install a new perl on the machine. Often political or social concerns override the obvious technical solutions. Especially when "legacy systems" are concerned.
| [reply] |
|
|
It's just hard for me to understand that you'd have the freedom to upgrade your development method to Subversion, but not be able to install your own private copy of perl. I thought I had strange politics to deal with at work ...
I've seen risk-adverse behavior wrt maintaining legacy systems, but usually there is some consistency to it. :-)
| [reply] |
|
