Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Production Environments and "Foreign" Code

by demerphq (Chancellor)
on Mar 12, 2003 at 18:27 UTC ( #242460=note: print w/replies, xml ) Need Help??


in reply to Production Environments and "Foreign" Code

we have almost a "no external modules" policy here, and are basically restricted to the "core" Perl modules and DBI.

Theres not much to add to this thread but a minor observation. The "core" modules have been evolving for quite a while. Not only that but there are several collections of "core" modules. ActiveState fwict bundles a _lot_ more into their releases than are in the "standard". Each new version of perl has a slightly different set of modules acompanying the code and not only that, they have different versions. (Does your company let you upgrade modules in the "core" from CPAN? Will it let you install a module that has been included in a later perl release but not in the one you use?) A few modules are IMO still in the core becuase they have been in the core for so long nobody wants to remove them, _but_ they have been generally replaced in new code by other more powerful modules anyway. File::Basename vs File::Spec comes to mind as example. Does your company have a policy about which of the two should be used?

Afaik the list of modules that is included is constrained more by space (how many users really are going to use Parse::RecDescent for instance?) and a modules utility to actually buidling perl itself than by the modules worthyness. Not that unworthy modules would ever make into a standard release, but that there are tons of worthy modules that will never get included because their user base wouldnt be large enough to burden every install with. (Space is already being discussed in some circles as being excessive.)


---
demerphq


Replies are listed 'Best First'.
Re: Re: Production Environments and "Foreign" Code
by Tanalis (Curate) on Mar 12, 2003 at 19:39 UTC
    Does your company let you upgrade modules in the "core" from CPAN?

    No.

    Will it let you install a module that has been included in a later perl release but not in the one you use?

    No.

    We're using Perl 5.004.04 (which I know is full of bugs and some quite serious security holes anyway). If it didn't come with that, we don't have it, and we can't get it, at least, that's the way it works at the minute.

    I agree, it's a crazy system, I personally think that it causes more problems than it solves. I'm all for CPAN - I use a lot of the modules from there in my own personal code, and I see no reason to use CPAN from a corporate point of view.

    I do think the current core module set is pretty well balanced, though: it allows a lot of development and useful reuse of code without bloating the distribution too much. Size seems to be very rarely an issue nowadays anyway, with disk space no longer costing what it did a few years back.

    -- Foxcub
    A friend is someone who can see straight through you, yet still enjoy the view. (Anon)

      We're using Perl 5.004.04 (which I know is full of bugs and some quite serious security holes anyway).

      You do what? No, seriously. I think there's something wrong with that attitude.
      I'm not arguing the usefulness of evaluation of software to be used in production - by no means.

      But this seems reckless to me. On the other hand, very probably your codebase actually relies on those bugs in external software (I've seen that oh so often ... :-( ), and if it does upgrading would be disastrous, indeed. But consider: How many people actually know the trouble spots in 5.004.04 and know how to avoid pitfalls. Is the primary reason to distrust outside code a missing test suite which ensures the robustness of your system?

      Is your staff actually a good enough team to tackle XML parsing on its own without taking years to do it right. Without hiding disastrous bugs in that code? And if they are good enough, wouldn't they be good enough to do proper code review on existing modules and feeding those bug fixes back to the community, serving others as you perfect your system?

      I know from personal experience that we employed external code (CPAN modules in this case) which contained bugs. We found them in our testing environment, fixed them and sent patches to the author.
      In other cases we looked into modules which supposedly did what we needed, but simply weren't usable. So we wrote ourselves.

      Ergo: By using external code, you don't have to use all external code there is. Which means: You can still write your own if you want/need to. Careful selection of modules is of course necessary as some others have noted above, too.

      janx

        You do what? No, seriously. I think there's something wrong with that attitude. I'm not arguing the usefulness of evaluation of software to be used in production - by no means.

        It's not always a bad approach to make. An environment with a large number of known bugs (which you can work around) can be better that an environment with unknown bugs - even if there are less of them.

        The cost of staying with a known system can be larger than the cost of migrating and discovering all those new bugs.

        Of course the cost of standing still increases with time as the rest of the world moves on.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://242460]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2020-08-09 15:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Which rocket would you take to Mars?










    Results (54 votes). Check out past polls.

    Notices?