|No such thing as a small change|
Modules, Frameworks, and Reinventing the Wheelby Velaki (Chaplain)
|on Aug 12, 2004 at 10:21 UTC||Need Help??|
I've recently noticed a trend, in which people are using more and more modules to the exclusion of all else. Now, I'm all for code reuse, good modules, and a great repository like CPAN, but when does it become too much?
My personal view is that a module should be a black box, but should have a well-defined interface, as well as supporting documentation. DBI comes to mind as a typical module. However, what is disturbing is to see people using modules to the exclusion of decent perl programming.
Silly, but dang near close, examples:
I see a lot of people using modules, without taking the time to
After all, using a module just to call one subroutine that might better be written as a simple regex bothers me. It you're going to use many of the rich features of the modules, or if it has something extremely unique about that one subroutine you need, then I can understand using it.
List vs Scalar context issues abound, and many people I've encountered appear unwilling to learn enough perl not only to know how to use the modules, but rather to know when to use them. I have seen projects stop dead, because new perl programmers were tasked with a project, and spent nearly all of their time trying to splice together a number of modules to achieve their goal, when they clearly didn't know if the modules worked, how they worked, and most importantly, WHY they worked; just that they were modules, and modules "do things".
When modules are used effectively, they provide a boon of coding wealth in the framework they become. Reuse is a good thing, and we are starting to see a more complete framework architecture in POE; however, reuse can be hampered through improper installation. I've encountered in my travels module suites half-installed, where one subcomponent works in one place, but not another, usually due to library and path issues. In an environment where changes, upgrades, and modification are slow to happen, this frequently has necessitated reinventing the wheel - something I am loathe to do when here are perfectly good CPAN modules that can be recombined to provide an effective solution.
Where is the line between overreliance on blackboxes and actual, justified use of them? Will the trend towards framework force perl programmers to hone their skills to take advantage of the architecture, or will it simply be the foundation for a generation of cruft to pervade perl programs world-wide?
Modules. Frameworks. Reinventing the Wheel. As you drive your projects, what will you do when you reach the four-way intersection of Module St. and Rewrite Ave. in downtown Projectville?-v
"Perl. There is no substitute."