A long-running argument has popped up again in the TWiki development community recently. Some developers, call them "half fullers", believe that the huge volume of code in CPAN is there to be used, and that developers shouldn't try to duplicate what someone else has already done. A lot of CPAN modules are pretty rubbish, but there are some incredible contributions there. What's more, someone else is maintaining them! What more could you ask?
The "half emptiers", on the other hand, see CPAN as, at best, a necessary evil. The argument is that CPAN modules are large (due to their desire to be generic) and often slow as a result. Worse, CPAN modules are hard to install for a novice or unprivileged user. Therefore in the name of "customer focus" CPAN should be avoided, and application-specific functionality coded instead. If that's not possible, the CPAN modules should be bundled with the application.
This argument seems to me to be a question that strikes at the very heart of Larry Wall's original concept for perl. Larry's goal was a language that is not the fastest, not the most elegant, not the easiest to maintain, but is the most fun to code in and is the quickest way to get the job done. CPAN is a critically important part of this; it provides pre-built and tested modules of common (and uncommon) functionality that you can just pick off the shelf and run with. OK, so they are not the best implementations in the world. But they are free, are already there, and do stuff you can't be bothered to do, or just aren't smart enough.
To me, the very idea of using perl as a programming language, and then not leveraging CPAN, is oxymoronic. If you want performance, then what on earth are you doing using an interpreted language? If you want installation simplicity, go and write an installer! It's hardly rocket science.
Of course, if you want to reinvent the wheel, that's fine with me. Just don't expect me to do it, and don't act all surprised when I swap out your homebrew code for a tested, maintained equivalent from CPAN.