This was prompted by a number of other threads and I wanted to get to the heart of this matter.

Let us consider the typical case of a production system undergoing enhancements currently, but which first incorporated several years ago, using say Perl v5.004 under either Linux or Solaris. In most cases, and certainly for mission-critical systems, all software goes through a lifecycle of development and three levels of testing (unit, integrated and acceptance), before getting through to production.

Suppose a new version of Perl (say v5.005) came out a year or two later. Before it could be taken through to production, all software developed in the interim would have to be tested against 5.005. That means almost the entire software life-cycle being repeated involving a variety of people from different teams, adding up to an overall expense that is hardly likely to be met by any compensating business benefits the developers can find.

Occasionally some major event will occur, such as a new version of some major package the system uses, whereby the Perl upgrade can be bundled in. But given the cost, such a miracle is only likely to occur about once in five or ten years for the mainstream of corporate systems. It seems normal enough that the version available for download of a CPAN module requires v 5.8 of Perl, whereas the production system will more likely be somewhere between 5.004 and 5.6.1. Maybe one day in the distant future that module may be compatible with these production systems but maybe the minimum for the version in CPAN will be 5.10 or 6.3 by then.

Impact for monks: So, in the meantime, most developers in large corporate environments need non-module programming solutions and core module solutions but cannot use solutions which refer to a non-core CPAN module and for these purposes, core means "core in the late 1990's"!

-M

Free your mind

Comment on Why non-core CPAN modules can't be used in large corporate environments.
Re: Why non-core CPAN modules can't be used in large corporate environments.
by rinceWind (Monsignor) on Dec 06, 2005 at 12:33 UTC

    PAR provides a good solution here. I have successfully used it to deploy Perl code into production, in an environment hostile to open source, and to Perl by implication.

    Using PAR, what I am delivering is a PAR executable, the source being a Perl script. Such an 'executable' is taken through a full development and testing cycle before being put live.

    Because PAR executables include perl itself, you eliminate the dependency on perl versions. You also eliminate the module interdependency nightmare that afflicts applications that use CPAN - this is moved back to 'development', where it belongs.

    Also worth mentioning is the isolation benefit that this gives you, in that each application so deployed, indeed each version thereof, is independent of every other application deployed.

    --

    Oh Lord, won’t you burn me a Knoppix CD ?
    My friends all rate Windows, I must disagree.
    Your powers of persuasion will set them all free,
    So oh Lord, won’t you burn me a Knoppix CD ?
    (Missquoting Janis Joplin)

      An interesting idea, although owing to the complexity and number of constraints I didn't even get round to mentioning in my OP report, it will take time to evaluate what PAR can do to help, but I'll certainly look into it, thanks for the suggestion.

      -M

      Free your mind

Re: Why non-core CPAN modules can't be used in large corporate environments.
by mirod (Canon) on Dec 06, 2005 at 12:46 UTC

    Couldn't "developers in large corporate environments" try to backport the modules to the version of Perl they are running?

    Instead of re-writing a module why not take a look at the code and see if you can patch it to work for you. You can even have the makefile pre-process the module if it finds that the running version of perl does not support some constructs. For example 3 argument open, use of our or even the qr// construct. Done properly this should not intrude on the code for quite a few modules. Oh, and don't forget to send those test reports for old versions of perl ;--)

    It seems like a win-win situation to me: you get a proper module in less time than it would have taken you to write it, plus support and new versions, and the author gets users, patches and a module that works on more systems.

      In theory yes, but what is logical for a developer is not always achievable in a multi-functional environment where many teams other than development have a say about what can go into production. In addition, Perl has to compete with other languages at that level and anything that looks like awkward procedure to non-developers can be hard to sell in that context - one might instead get asked to propose a non-Perl alternative solution.

      -M

      Free your mind

        Every non-trivial technical package has this problem. Also, if the "non-developers" are making all the decisions without developer input, I guess I'd have to ask "why?". Who better to assess the situation than the guy that has to deal with it? Also, how much money are you spending re-inventing wheels?

        thor

        The only easy day was yesterday

Re: Why non-core CPAN modules can't be used in large corporate environments.
by tirwhan (Abbot) on Dec 06, 2005 at 13:16 UTC

    Seems to me like there's a logical fallacy in your argument. Just because some/many modules on CPAN don't work for the version of Perl used on your production systems does not mean none of them do. Naturally, when looking for a solution to a problem you should take into consideration whether a given CPAN solution works for your production environment, that seems to me as obvious as not trying to use Win32:: modules on a *NIX system. But you should not conclude that you cannot use any CPAN modules because some of them don't fit your needs.

    Also, some developers make an effort to keep their modules as backwards-compatible as possible, and if you tell a developer that you would like to use his module but can't because your version of Perl is older than his module's minimum requirements he may try to adapt the module to suit your needs (especially if your request is accompanied by a suitable patch, as suggested by mirod :-).

    And I'd posit that a good system should be written with upgradeability of the underlying platform kept in mind, and a cardinal rule for that is "don't use undocumented or deprecated features". I am perfectly aware that this is often not possible without huge effort (particularly since the time-machine which lets you preview future features of Perl seems broken again), but it should be one goal when writing such a system. Sticking to old and deprecated platforms can create massive problems at a moment's notice (like when a serious security flaw is suddenly found and no fix is backported), and while it's sometimes unavoidable it should not be a goal IMO, or considered "the way things are done".


    Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
      Viewing facts as an argument seems surreal to say the least. View it instead as rule gained from long term observation and I assure you that exceptions are so few as to be negligible at the business level I am addressing.

      If you study my OP more carefully you will see I have already explained why upgradeability of a system is not under the full control of its writers and designers and that therefore your ideal is an impossible one within most scenarios I am encompassing.

      -M

      Free your mind

        Well, you're latching onto one part of my argument where I'm saying that the situation you describe is evidence of poor planning on someone's part (if the development team was involved in setting up this system it's poor planning on their part, if they weren't involved it's poor planning on the part of the PHB who's not intelligent enough to listen to advice from technical people on technical matters). Sure, if you're caught in this situation it doesn't help for me to say you should avoid getting caught there. But it may help others who are not yet stuck in this avoidable rut.

        I'm afraid (judging from past posts I've seen by you) that I do not trust your assurances on what is "typical" and would rather trust my own experiences, thank you very much.

        And of course the logical fallacy (which was the larger part of my post) remains.


        Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
      Seems to me like there's a logical fallacy in your argument. Just because some/many modules on CPAN don't work for the version of Perl used on your production systems does not mean none of them do.

      Indeed, this is called the fallacy of composition, commonly summed up in the phrase, "don't throw the baby out with the bath water." And it's exactly what Moron has done with his post. It's heartening to see all the monks who picked up on this and are trouncing it superlatively.

Re: Why non-core CPAN modules can't be used in large corporate environments.
by perrin (Chancellor) on Dec 06, 2005 at 13:52 UTC
    Backporting a module is likely to be faster than writing from scratch. If they can put their own code through to production, they can put code that they backported through as well. Many CPAN authors would appreciate receiving backport patches, especially well-tested ones.
      True, although once you get into the guts of that, it seems more appropriate to use technique from the module to fit your system - the functionality the module delivers in such situations is usually small compared with what has already been developed for the target system, so it is often easier to move Muhammed to the mountain than vice versa.

      -M

      Free your mind

        Sure, just glance at the DBI, HTML::Parser, Template Toolkit, and LWP source code, and then write your own. Have fun.
Re: Why non-core CPAN modules can't be used in large corporate environments.
by BrowserUk (Pope) on Dec 06, 2005 at 14:06 UTC

    That argument makes no sense whatsoever.

    At the point in time where a new application is developed & tested,i.e. pre-production; it is completely acceptable to use whatever CPAN modules that are available at that time, in the development of that application.

    For existing applications, if you are adding new code to the codebase, regardless of whether that new code is developed totally in-house, or utilises one or more CPAN modules; you still have to go through the same, identical testing process.. The only time you avoid testing, is if you make no changes at all. And if you are making no changes, the subject of CPAN modules doesn't arise.

    What you appear to be saying is that if you are developing a new application, and already have an existing one in production that uses some ancient version of Perl, and is so badly coded that you are scared to upgrade it, that your new application has to use that same ancient version of Perl. That's stupid.

    It is entirely possible and practical to have multiple versions of Perl installed for different applications. Just don't add them to the path. Put the appropriate version of Perl into the application subtree and put a simple shell command into the path for each application that sets the path up for that application and invokes it.

    Call it "loose coupling", "breaking dependency chains", or "application independence management". Avoiding locking your entire development effort into choices made and facilities available 5 or 10 years ago is the first thing on the curriculum of 'Business Application Management 101'.

    It's the same lesson that was being learnt in corporate development shops in the mid '80s about getting locked into a single language or version of a compiler. Eventually, and sooner rather than later, the supplier of the compiler will drop support for the version you have selected as your 'one and only'. Or worse, the supplier will go bankrupt or be bought out and the compiler will simply become a zombie.

    If each new development is made with the latest, stable, tested and certified version of whatever language/compiler makes sense for the project, when support for old versions is dropped, you only need to upgrade those projects that made use of that version--not your entire application suite.

    You also get the side benefits of:

    • Each project benefits from the latest technology.
    • Each project can choose the language/compiler most appropriate to it's requirements.
    • Each project can benefit from the availability of new third-party libraries that become available between projects.
    • When the crunch comes 10 years from now and you are forced to upgrade projects that used tools that are no longer available or supported:
      1. Only one or two projects are affected each time.
      2. You don't find yourselves scrabbling around, paying premium prices for the very limited pool of programmers that have any residual expertise in that obsolete technology--at exactly the same time as every other company locked into it will be doing the same thing!.

    I realise that companies are still making this mistake--in some cases for the third or fourth time in the last 30 years--, but if you have any influence whatsoever when the a new generation of bean-counters re-invent the "All new development will use version P.Q.R of language/compiler XYZ from now till doomsday (or the sh*t hits the fan)" directive; gently point out that 'doomsday' and 'the sh*t hitting the fan' are the same thing, and like all non-specific statutes of limitation, it always arrives sooner rather than later, and much sooner than their spreadsheet projections predict.

    Actually, sod "gently", do it forcefully!


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Viewed only as an argument from one's ivory tower of development, I agree it makes no sense! More's the pity that it's real instead then!

      Update: On second thoughts, looking at the amount of unwarranted fantasy you are reading into my post, I take that back - there is little point in my commenting further under the circumstances.

      -M

      Free your mind

        And that sounds like a ploy from the Ostrich school of issue avoidance :)

        You'll note that I didn't say that the situation didn't exist, only that the argument and logic behind that situation doesn't make sense.

        And that those finding themselves newly or repeatedly subject to this type of illogical and nonsensical edict, should stand up and be counted by making those responsible for those edicts realise how illogical and counter-productive they are.

        Explain to them that they are constricting the life out of the development process, and so increasing development costs of new projects by preventing code reuse, and condemning those new projects to ignore or recreate the enhancements, or work-around the bug fixes, in newer development platforms and tools.

        And they are doing this in favour of unrealisable savings on old projects. Unrealisable, because they will only save money if those old projects never change, and if they never change, they won't cost anything anyway.

        As truisms go, "Those who cannot remember the past are condemned to repeat it", is pretty much in a class of it's own. Unless you have experienced it's truth, you won't appreciate it until you have, at which point you'll have proved it for yourself.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Why non-core CPAN modules can't be used in large corporate environments.
by adrianh (Chancellor) on Dec 06, 2005 at 14:34 UTC
    So, in the meantime, most developers in large corporate environments need non-module programming solutions and core module solutions but cannot use solutions which refer to a non-core CPAN module and for these purposes, core means "core in the late 1990's"!

    Having been doing commercial perl work for nearly ten years now I can only think of two clients who did not use CPAN modules all over their code. They were, in my opinion, idiots and wasted time and resources reimplementing stuff that was there to download. And in one of those instances it was because they were "scared" of open source rather than due to any maintainability issues.

    Three things make this a non-issue:

    • Most of CPAN works quite happily on older perl's. I've recently been doing a bunch of work on a codebase that uses 5.6.0 for reasons to dull to go into. 99% of everything still "just works"
    • In the cases where it doesn't work the source code is available. Most of the time it's easier to backport than it is to reimplement

      .
    • Any professional organisation has roll out processes, test suites, etc. That make migrating code to newer versions a business issue, rather than a technical issue.

    So pretty much a non-issue in my experience.

      I said large corporate organisation such as a bank or a telco and I also mean to exclude large software or consulting operations from the problem I am talking about.

      -M

      Free your mind

        I said large corporate organisation such as a bank or a telco and I also mean to exclude large software or consulting operations from the problem I am talking about.

        The telcos and banks I've worked for are large software or consulting operations. Hell I've been involve with some banks that have taken their compiler development in house!

        This has nothing to do with the scale of the organisation. This has to do with how you organise your software platform and the business risks associated with that platform.

        This is nothing specific to Perl and CPAN. It applies to any language and system that involves third party code.

Re: Why non-core CPAN modules can't be used in large corporate environments.
by radiantmatrix (Parson) on Dec 06, 2005 at 14:38 UTC

    I find your reasoning a little suspect:

    Suppose a new version of Perl (say v5.005) came out a year or two later. Before it could be taken through to production, all software developed in the interim would have to be tested against 5.005. That means almost the entire software life-cycle being repeated...
    In fact, that isn't typically true. All that's required to move from one version of Perl to another would be regression testing, which is typically automated, followed by a brief UAT period. If there are problems, then you can get into software development cycles, but such problems don't often occur (and are typically failry minor when they do).
    It seems normal enough that the version available for download of a CPAN module requires v 5.8 of Perl, whereas the production system will more likely be somewhere between 5.004 and 5.6.1.
    There are not all that many modules which require 5.8.x. Most of the time, when I see people asking about solutions that use core modules only, the CPAN modules that would solve their problem work just fine with quite old versions of Perl. A more reasonable request would be "I have perl 5.6.1 and that can't be helped: so I can't use any modules that depend on newer versions." Unfortunately, that's not what we see, most of the time.

    There are only two common reasons for a corporate requirement of "no CPAN modules": code vetting and licensing.

    In many organizations, any production code must be vetted by Quality Assurance (QA) and Security Review (SR) teams. Sometimes both functions are performed by QA. In any case, the core Perl distribution tends to have been vetted by these teams as safe for production use. All code written in-house will follow corporate coding standards and is therefore a bit easier for QA/SR to clear for production. CPAN modules (a)are a bit harder to review and (b)might have to be handled outside the project, slowing production. It would be easy enough for a corporation to establish a better review process for CPAN modules, but often they apply the same rules that were designed for external modules in other languages (which often do not have source code). The coder on the floor doesn't usually have enough pull to get the policy adjusted.

    As for licensing, many CPAN modules are GPL or a similar "viral" license, and that makes legal types nervous. We all know that using modified GPL software internally creates no burden, but corporations tend to be risk-averse and would simply rather avoid the potential for licensing concerns. Thus, policies grow that forbid external modules without a long and painful code- and license-review process.

    <-radiant.matrix->
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    "In any sufficiently large group of people, most are idiots" - Kaa's Law
      I was not really speaking hypothetically, but rather using a scenario to represent the real situation within certain branches of industry..

      -M

      Free your mind

        Everyone has a relatively limited view of how industry functions, because that knowledge comes from personal experience. I was merely sharing my personal experience from the several years I've been contracting in and around various industries. While what you experienced is obviously fact, it is not the whole story, and is not, as you postulate "the reason" for restrictions on CPAN.

        Your reasons also don't seem to apply to the majority of questions we see on PerlMonks, because most of the recommended CPAN modules to solve the problems at hand work with very old Perl versions.

        <-radiant.matrix->
        A collection of thoughts and links from the minds of geeks
        The Code that can be seen is not the true Code
        "In any sufficiently large group of people, most are idiots" - Kaa's Law
Re: Why non-core CPAN modules can't be used in large corporate environments.
by dragonchild (Archbishop) on Dec 06, 2005 at 15:17 UTC
    It seems normal enough that the version available for download of a CPAN module requires v 5.8 of Perl, whereas the production system will more likely be somewhere between 5.004 and 5.6.1. Maybe one day in the distant future that module may be compatible with these production systems but maybe the minimum for the version in CPAN will be 5.10 or 6.3 by then.

    Setting aside the fact that most modules on CPAN take great pains to be backwards-compatible with at least 5.6.0 (or earlier!), you can always see every single upload to CPAN through use of the BackPAN. So, you can always get at the version you want to use today, but can't until next year.

    As for version compatibility on CPAN ... I'm of two minds. In Excel::Template, I actually have an eval-block to determine if I can use 3-arg open or if I'm at a version that requires 2-arg open. In PDF::Template and PDF::Writer, I require 5.6.0 at a minimum. I don't depend on 5.6 features, but I feel that it helps stabilize my testing burden because I don't need to keep a bunch of different versions of Perl around. Now, if there was an easy way to have Test::More or Module::Build run a test suite against various versions of Perl and report errors by Perl version, I would change my tune. Or if there was documentation of how to tune your code to be more in tune with the version of Perl it's running under, then I'd have no problem. Older versions of PDF::Template actually have provisions for whether or not to use Unicode::String based on Perl version, but it uses PM_FILTER which is marked "DO NOT USE" in ExtUtils::MakeMaker and I haven't seen the way around it in Module::Build.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      Thanks, that's all useful information in addressing such problems.

      -M

      Free your mind

Re: Why non-core CPAN modules can't be used in large corporate environments.
by Perl Mouse (Chaplain) on Dec 06, 2005 at 15:21 UTC
    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:>*
      Sorry, but that information would compromise my privacy.

      -M

      Free your mind

        To be fair to 'Moron', I blame the sys admins for this.

        Handcuffing us developers(for their own pleasure) so that we can't use the best tools for the job:)

        However if you upgrade every 5 or ten years it goes without saying you are losing competitive advantage to those companies that are more flexible.

        A cpan module is as non-core as your own modules so by that logic u can't write any code in corporate environments

        Large coporations are actually more likely to have good sys admins, change/version management processes and strong testing procedures that may be needed.
      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:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Why non-core CPAN modules can't be used in large corporate environments.
by Tanktalus (Canon) on Dec 06, 2005 at 17:55 UTC

    Side note...

    I've faced this problem. I tackled it. (With actually some good help from my first line manager - possibly higher, I'm not sure.) We now have multiple versions of perl in production. Older code uses older perl, new code uses newer perl. In fact, my code runs on perl 5.8.7 on Unix/Linux and 5.8.6 on Windows (due to a problem we had on unix/linux which wasn't relevant to windows - no desire to upgrade windows again), while the code from other teams runs on 5.8.1 or 5.6 or even 5.005.

    The 5.8.7 install has the 5.8.6 lib directories in its hardcoded @INC. The lib directories are shared across all platforms (including Windows, I think). And I have a way of hacking in new CPAN modules at runtime (thus far, they're all pure perl which makes it trivial, not sure if I'm brave enough to try XS or Inline::* code...).

    This is a fairly large software company. (Our building has about 2500 people - software developers and support, such as IT, management, customer service, HR for software development, but not sales, corporate management, lawyers, etc. And we're not the only developers in the company.) It's just a matter of aligning the priorities and making sure everyone gets what they want. Management wants to ensure nothing is broken. Thus, keep the old versions of perl. Management also wants fast development. Thus, new versions of perl need to coexist in a way that allows us to get new CPAN modules.

    I actually got this ball rolling when we started investigating XML-based technologies. There was no way I was going to do that by hand - I got my manager behind the idea that we needed XML::Twig. And we pushed from there - "No way to hit our dates without this." As in, yes, we can do it, but not by the end date you want it to be done by. That brought extreme amounts of pressure to resolve the situation.

    Of course, if your management says, "Ok, we'll move out the dates," then that's what you do. You rewrite stuff that would work fine if they were willing to have a parallel perl that was up to date. But they're willing, instead, to pay you to reinvent some wheels. That is their perogative. ;-)

      If you write your own module you are not re-inventing a wheel just because someone else attempted to make a generic version with none of your specific requirements but some general ones intended for diverse systems. The author of a module has never even seen the requirements you have and it's suitability is not really as likely as people hope. It just appears so because most people are lazy.

      -M

      Free your mind

Re: Why non-core CPAN modules can't be used in large corporate environments.
by TomDLux (Vicar) on Dec 06, 2005 at 19:37 UTC

    At the mega-corp where I work, the administrators have mechanisms to provide different versions of Perl ( & Vi & Emacs & Informix & Sybase & .... ). Last year they stopped supporting Per 5.005. Modules are available in multiple versions, and a special versioning feature is used prior to the 'use' statements to specify which version of a module to use.

    That makes it the responsability of the programmer to update script X from Perl5.6 to Perl5.8, or to move from one version of DBI to a more recent one. There's no reason for my monitoring script requirements to affect the performance of your data loading script.

    Just this week I am migrating a set of scripts from 5.6 to 5.8. I didn't want the bother, until now, but a bug has appeared which makes the migration necessary.

    --
    TTTATCGGTCGTTATATAGATGTTTGCA

      I can't see that happening here -- the developers would not have a budget to make such a change, the system would fail and the administrators would go to jail. (Obviously in practice they would back down long before it got to that.)

      -M

      Free your mind

Re: Why non-core CPAN modules can't be used in large corporate environments.
by ysth (Canon) on Dec 06, 2005 at 21:16 UTC
    In several places in this thread, you use the term "multi-functional". Can you explain what it means to you?
      Users, data managers, analysts, application supporters I (of inhouse applications), application supporters II (of other applications), system administrators, DBA's, developers, functional testers, specifiers, UA testers, ...

      -M

      Free your mind

Re: Why non-core CPAN modules can't be used in large corporate environments.
by Juerd (Abbot) on Dec 11, 2005 at 00:30 UTC

    You seem to ignore the simple established fact that

    non-core CPAN modules are used in large corporate environments.

    Very rarely I respond to only the title of a node. But in this case, it's so dumb that I could not resist.

      I recommend 'Po, beyond yes and no' by Edward de Bono, to help unscramble the dependency on contradictions in your system of perception. In this case there is no actual contradiction.

      -M

      Free your mind