one friend of mine is a sysadmin in a finance company, and there are policies in place explicitly forbidding the use of CPAN modules.

I hate to say it, but there is a lot of merit in that approach.

No, really, there isn't. Wherever possible, risks should be managed, not simply avoided. And CPAN is a manageable risk.

A policy that does have merit is "no unaudited CPAN modules". It makes sense to control the code coming into your systems; it makes sense to check the licenses and to perform due diligence in (for example) looking at the bug trackers, reading module reviews, looking over the code for nasty smells, and finally installing the code on a development server and checking that it isn't likely to break anything in the operational environment. And, of course, it makes sense to require people to present a good business case before you allocate the resources to do all that work.

It does not make sense to automatically reject all third-party code. You will waste time and money reinventing wheels. Has that place seriously even written their own versions of stuff like DBI?! If so, they'll have ended up with something that probably contains more bugs, performs worse, and behaves differently from the standard interface that everyone else in the world uses. And to this day they'll be wasting even more time and money maintaining it themselves, instead of letting other people take care of that while they put all their resources into doing their core business well. This is not the path of merit.

Comment on
Re^2: What is the best way to install CPAN modules on Debian?

It does not make sense to automatically reject all third-party code. You will waste time and money reinventing wheels. Has that place seriously even written their own versions of stuff like DBI?!

I'm only passing on what I've been told... It's hard to imagine a profitable company in an extremely competitive and fast-paced business that doesn't have a protocol for working around policies where they are counter-productive. I assume there is a process in place whereby CPAN code can be vetted, tested, approved, and added to some sort of whitelist.

The immediate effect on my friend, however, is that he can't search CPAN whenever he runs into a wall with his Perl. When he calls to bounce ideas off me, he generally adds the caveat: "I can't use CPAN."

If we imagine a company with even the most stream-lined vetting process, we still end up with a scenario where a sysadmin's one-off monitoring script becomes a several week effort while he waits for approval for that module. Home-rolling is faster. Even with intense testing and debugging, it'll get the code across the finish line before a module passes review; and a sysadmin doesn't care about portability: the code she is writing has to run on a very specific platform. That removes a huge amount of effort that goes into anything on CPAN.

People in that environment aren't writing frameworks. As far as I know, neither my buddy's employer nor I have ever advocated re-writing a generalized framework like DBI. That's what Paul Graham calls a "pathological edge-case."

In a case where sensitive data is potentially exposed, or where loss of service is measured in millions of dollars per hour, the loss of developer and/or administrator time re-inventing a lot of wheels is negligible by comparison. Additionally, in-house code doesn't have to be portable: operating platforms are concretely known and change very rarely.

From a coder's perspective, using 3rd-party modules makes a lot of sense. But there are business scenarios where it's just not the right thing to do. And in some cases, it's been decided to reject foreign code by default for very sound business reasons. That's my only point.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other