|
Over Using Modules
More and more I see perl
programs that look like no more than a call up of 10 or more
modules. Most people will tell you that is efficient code. Not me.
Calling modules is fine and
very useful. But every module you depend on can change in new
publications and can stop your program from working on other
servers. That is the primary problem.
The next problem is the system
resources to call and run several modules rather than one single
program. And, like most cases, people will tell you the system
resources are insignificant. Of course, that will come from
people that have never challenged high end servers.
Its like having a table that
supports 100 pounds. Great to eat at, utill the family shows up
for Thanksgiving and you dump 2 30lb turkeys and a tub of mashed
potatoes. The table will colapse ruining the meal and costing
your time and money.
The usual response is that, it
has work for the last year, no problems. That is, until you
really needed it.
Programs are the same.
Runing a business that is so
dependant on perl modules is like trying to run a restaurant
serving frozen TV dinners.
Since everything is
preprepared, you have little contol over the programing. And if
you don't know the code, you are open to every exploit that a
module may have.
It is difficult to build on
modules, since you only know the ins and outs rather than what
the code is actually doing.
I am not against modules, they
are great. But using 10 in one program is just foolish.
Many times a perl module is
called and the function can be written in a few lines of code
witing the program.
I have seen modules called to
format the date, when a simple /bin/date command will do it for
you.
Using object oriented perl is
great. But at some point, you need to make your code unique. To
have something that is not commercialy available you need the
ability to go beyond the modules and write unique code.
Don't be afraid to actually
write code. It will get you much further and allow for greater
expansion of your applications.
|