|
How Does Object
Oriented PERL compare to Rube Goldberg?
OK, maybe comparing technology
with Rube Goldberg contraptions is a bit extreme, or is it?
In many cases modules are used
because the programmer does not know how how to wrire the code
themselves. Or, they just want to save time and the client money
by streamlining the process. But does that really accomplish the
task?
So lets look at a typical Rube
Goldberg machine.

The boot kicks the ball and
the ball lands in the strainer tiping the wattering can and the
water weighs down the lapels opeing the bird cage letting the
bird eat the worm and i am not sure how that gets the letter to
the mailbox, but I am sure the programmer does.
I think this is a great
analogy of a program using moules. Lets look at a programming
sample.
First we start off with
#!/usr/bin/perl
use BOOT::OnHook;
use Basket::TiedToPail;
use BirdCage::Opener;
use Worm::OnString;
if ($start = $boot->athook)
{ &tip_pail;}
if ($lapels < $weight_of_cage){
&open_birdcage;}
while ($birdeatsworm > 1) {
&mail_letter;}
OK, maybe I am being carzy,
but here is my point.
If the bird is sleeping, then
the machine does not work. If the bird is not a worm eating bird,
the machine does not work If the bird is not hungry, the machine
does not work.
This is the major problem with
modules. You don't really have control of the module and what the
module is doing. You did not write the module, so you don't know
what the module is capable of or how it can fail.
Will BOOT::OnHook fail if you
try to use a shoe instead of a boot or if the boot you use is too
heavy or uses to much memory your program could fail.
Making matters wors is that
you have a string of modules that you can't plan for. You don't
really know what the modules are capable of or what holes that
may have. Some modules wont work ogether under certain conditions.
If you use a module to pars
data or an input, you are only going to have the output to work
with. Lets say you throw a new character in the mix like ~ and
the module can't parse out the character. The program will fail.
But you would never know that you have a fail condition since you
don't know what the module is doing.
Worse, what if the charater or
input opens a vulnerability in your program.
For example many programmers
use CGI.pm to parse forms. It can also be used to upload content
to your server and open holes in your security.
If you use an upload form the
module will allow you to set the size limit of files to be
uploaded. BUT, the module takes the file and writes it to a temp
file to check the size. If you have someone trying to upload a 10gig
video file it could crash your server before it realizes that the
file is bigger than you allow.
An alternative is to read the
input length and decide if you want to to accept the file. Of
course then you could bury your ram by taking the 10gig file into
memory.
There are always going to be
risks, but when you take on modules that you don't fully
understand the risks are greater and leave holes that can
potentially take down a server, comprimise security or just case
programs not to work in certain conditions.
My advice is to stay away from
modules or rewrite the code in a sub you call from your program
with the require command if you want to shae it between programs.
I am hoping bumblebeeware will
give people a boot at becoming real serious perl programmers and
not Rube Goldberg style programmers.
One of my biggest concerns is
that every end user or site owner that gets a perl program that
does not work efficiently blames it on PERL. So every bad
programmer contributes to the downfall of the language overall.
Currently there are so many
PHP programmers that the market is flooded with bad code and
programs that wont run on shared hosting. Peopel are starting to
blam PHP for being slow and resource heavy. But the fact is, it
is just bad code. PHP by design is extremly efficient.
The same is true for perl. But
if you ask perl to open a file that is 1gb, its not perl that is
eating system resources, its the programmer that had no idea that
the module they called did not plan for a programmer that would
not limit a file size.
I hope my comparison will open
your eyes and help you reach deep for good ideas rather than just
grabbing modules to perform every task.
|