Re: Why non-core CPAN modules can't be used in large corporate environments.

The number of things new in 5.8.x as opposed to 5.6.x are extremely limited - and if they were it's mostly things that weren't possible in 5.6.x or are vastly improved (threads, Unicode).

The change between 5.005_xx and 5.6.x is bigger, our, lexical warnings, and autovivifying of filehandles come to mind.

Hence, a CPAN module either uses something specific to 5.8.x (and hence, you wouldn't even attempt to use it in 5.6.x), or it's just going to work in 5.6.x. And even if you're dragging 5 years behind in perl releases, you're on 5.6.x. 5.6.0 was released in March 2000.

BTW, you are talking about most developers in large corporate environments. Where does that statistic come from? How many large corporate environments do you have experience with?

Perl --((8:>*

Comment on Re: Why non-core CPAN modules can't be used in large corporate environments.

Replies are listed 'Best First'.
Re^2: Why non-core CPAN modules can't be used in large corporate environments. by dragonchild (Archbishop) on Dec 06, 2005 at 16:56 UTC
I don't mind compromising my privacy (because I have done so already on this site). In my experience in at least six major corporate environments (including a bank and a credit card), things are often how Moron describes them. However, the larger and more stratified the environment, the more often you see the rules being broken. For example, in $HUGE_BANK, the requirements for Perl version varied wildly from group to group and even app to app. I remember having to comment out "use warnings;" in a sysadmin script because the version on the one server they were running on was 5.005_03 while the sysadmin (who wasn't there) was used to running his private 5.8.4 install. In $CREDIT_CARD, we were up-to-date on Perl version, but a version behind on PDFlib and 2 versions behind on a middleware. The key to these decisions was $$. Perl was free, so the upgrade could be done when the developers had time to evaluate. Everything else cost money, so the upgrade could only be done when the funds were approved AND the developers had time to evaluate. Which do you think happened quicker? Things like this often depend very heavily on the first and second layers of management right above the senior developer vs. some random corporate policy. Anything above the manager's manager and they don't want to know the details. If your manager's manager has lots of clout, you get stuff done. If they don't, you likely end up finding a new job cause you hate it where you're at. shrugs At least, that's my take on it. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.