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

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.

  • 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 Moron (Curate) on Dec 06, 2005 at 14:26 UTC
    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

[reply]
      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

[reply]
        The minute an issue goes multi-functional it enters a political arena. The developer may theoretically be able to give input to such an arena, but usually they lack the verbal skills to make an impact at that level. If your experience is otherwise consider yourself lucky.

        To address your last point, a non-module solution is not necessarily a re-invention of the wheel; indeed instead of backporting there is yet a third option: just copy the parts or even ideas you need from the module rather than treating its use as an all-or-nothing proposition and suddenly the developer is king again - I used that method to sneak Devel::Trace into a Q/A environment.

        -M

        Free your mind

[reply]
          A reply falls below the community's threshold of quality. You may see it by logging in.
Re^2: Why non-core CPAN modules can't be used in large corporate environments.
by DrHyde (Prior) on Dec 07, 2005 at 10:23 UTC
[reply]

In Section Meditations