Syntactic Confectionery Delight | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Recently a Seeker ran into some trouble with an example script from a
popular Perl textbook, and the immediate response from a prominent
monk was "Don't reinvent the wheel! Use module X instead!"
This surprised me, as I thought learning how the script worked would
be a worthy goal.
But the conflict in opinion brings up a larger question: at what level of program detail is it best hand off duties to a black box, i.e., a Perl module? And if a module is used, what sort of effort should one make to understand its innards? One of the greatest strengths of Perl is the massive CPAN library of modules available. Code reuse really works here and allows me to be Lazy, in the good sense of not wasting time duplicating fine work already out there and Impatient, in the sense that I can write powerful programs quickly. But at the same time there is a danger of not really learning about the problem I am trying to solve. I might learn just enough to realize that there is a module that can solve part of my problem. After downloading the module, I might skim just enough of the synopsis to cobble together some code. If it works, great! But if not, I am in trouble - I don't know enough of the underlying structure of the problem or the module to figure out if the bug is in my driver program, my interface code, or the module. Worse, if it sorta works, I might be tempted to not to bother trying to figure things out, because, hey, I've got more important things to do than noodle about in the details. This is laziness and impatience at its worst, and can lead to Cargo cult programming. For instance, if one was to implement a multitasking server there are several possible approaches:
-Mark In reply to Use modules or roll your own? by kvale
|
|