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:
use Math::Simple;
my $math = Math::Simple->new(5);
my $result = $math->add(6);
or
use Perl::Program;
my $program = Perl::Program->new("My program");
$program->write_it_for_me; # Why doesn't it work?!
I see a lot of people using modules, without taking the time to
- read the documentation
- understand how perl will use the module
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."
|
Re: Modules, Frameworks, and Reinventing the Wheel
by Aristotle (Chancellor) on Aug 12, 2004 at 10:45 UTC
|
Overuse of modules is only a manifestation of the problem, not the problem itself. The problem is that, just like real programmers can write FORTRAN in any language, beginners will write awkward or coincidentally working code regardless of which paradigm has been hammered into them.
Makeshifts last the longest.
| [reply] |
Re: Modules, Frameworks, and Reinventing the Wheel
by tinita (Parson) on Aug 12, 2004 at 10:56 UTC
|
just some thoughts:
regarding reinventing the wheel - i've written a template-system once (now
i don't use it anymore, there are much better ones), i've written my own
XML::Simple extension which did something extra (i could have just used
another module because XML::Simple is designed to be simple), and i'm
writing my own framework now although there are already some (well i started
to do this before there were really usable frameworks).
i think it's necessary that people are reinventing the wheel. they learn,
and maybe they learn that it's just better to use an existing solution.
maybe the write a better solution, and that's good.
without people doing that there wouldn't be so much solutions to choose from.
usually at some point there are three or four solutions which come out as a
standard, e.g. use HTML::Template, if you want an easy solution which is
easy in both using the module and coding the template.
when i'm coding something, even if it's a small program, it also helps
me to encapsulate things in modules (especially in OO). i don't do uml specs
(when i'm coding alone), so i think about what functionality i want, and
create a class. if i want more functionality i usually first use it in the
main script like $object->do_unexisting_functionality() and
then add this method to the class. i just find it more maintainable. but
maybe that's just a personal preference. just my 2 cents.
Update: about too much modules - i recently installed Maypole. i did
perl Makefile.PL etc. for every single PREREQ_PM. i didn't count how much modules
i installed recursively on that afternoon, but it was incredible. lots of the required
modules were probably just optional but were in PREREQ_PM, so i maybe installed
20 modules i will never use. but hey, disk space is cheap ;-) | [reply]
[d/l] |
|
|
but hey, disk space is cheap ;-)
On your own machine maybe but it's a different story when you ssh into your virtually hosted webspace and have to install all this with your own bandwidth.
| [reply] |
|
|
but it's a different story when you ssh into
your virtually hosted
sure, that's why there was this little thingie ';-)'
i had this problem myself recently when i installed PAR on my 100MB webspace.
disc quota was full =(
in the end i compiled at home and just copied blib. fortunately both systems have
v5.8.x
| [reply] |
Re: Modules, Frameworks, and Reinventing the Wheel
by gunzip (Pilgrim) on Aug 12, 2004 at 13:55 UTC
|
This touches on the larger issue of learning programming with high level languages coupled with large code repositories. The new student often learns the basics, well or not so well. Then it all grinds to a halt. Theses days the idea of writing your own code as a beginner becomes moot since you're constantly advised not to re-invent the wheel. 'Trouble is, how else do you become proficient with a language if you don't write code with it? Now the wheel has been perfected what is there to do? New programmers inevitably end up doing nothing more than marveling at the design of someone else's code.
Another issue is quality control for CPAN. How do new students know if a module is any good?
| [reply] |
|
|
Trouble is, how else do you become proficient with a language if you don't write code with it?
Strawman. No one's telling you not to write code. People are telling you "Don't write bad code to solve a difficult problem badly." You can ignore that, of course, but please don't distribute code like that without running it by some smart and experienced other people first.
The thing is, you can become a good and experienced programmer by ignoring what the good and experienced programmers tell you. It'll just take a lot longer and be a lot more difficult than if you listened to them when they said "I did it the hard way; this way is easlier."
How do new students know if a module is any good?
Ask people you trust and who have experience for their recommendations.
| [reply] |
|
|
I agree. Asking people you trust is good; however, I've noticed that the people the new ones trust -- where I work -- go by the concensus of the local perl experts chatroom, which is never of one accord, since many of the "experts" in there are just as green as the ones asking the questions. Hence, all the module overuse, and no one appears to have learned the whys and wherefores of perl enough to give reasoned opinions. They simply chant, "Module::Module::Module."
As I've said before, I'm all for modules. They're good for what ails ya, but it's like going to the doctor and upon being asked, "Where does it hurt?" replying, "You're the doctor. You tell me."
I would rather see the new programmers understand perl, and know why they're using the modules, and how the modules help them, rather than bolting together a disjoint set of modules, and gluing them together with really nasty code.
Maybe I should start some basic perl lectures to help the new programmers learn how to use modules more effectively, by showing them how their implementation and glue code may be written.
-v
"Perl. There is no substitute."
| [reply] |
|
|
Noone is telling you what to do on your own time.
But please don't reinvent wheels in production code, unless you know how to make your wheel rounder than the existing ones.
Makeshifts last the longest.
| [reply] |
Re: Modules, Frameworks, and Reinventing the Wheel
by synistar (Pilgrim) on Aug 12, 2004 at 13:57 UTC
|
I find that when writing web applications I use a fair amount of modules (HTML::Template, CGI::Application, etc.) . However, I generally stick to writing my own frameworks because generally I can customize a framework that I wrote much quicker than I can absorb the architecture of someone else's framework and then decide if it is a good fit for my app or if it needs retrofitting.
I think that in general most people tend to re-invent the wheel instead of doing a cpan search. And in some cases I think it is justified. Of course there is no point in doing it when there are "standard" modules that already do exactly what you need (templating, database, etc.).
And I do have to confess that I did write my own templating system a while back, and it is still in use in production systems. <bows head in shame>
| [reply] |
Re: Modules, Frameworks, and Reinventing the Wheel
by perrin (Chancellor) on Aug 12, 2004 at 16:47 UTC
|
I think everyone can agree that a module that adds a function you already have, like addition, is silly, and without a more concrete example it's hard to say much more about it. I'd consider nearly any use of CPAN modules to be justified if the module adds significant required functionality. 50 modules? sure, go ahead.
What's more interesting to me is how different your experience with Perl newbies seems to be from mine. When I was looking to hire a junior person, 99% of the people I talked to claiming to be Perl coders had barely even heard of CPAN. They had all used DBI, and maybe CGI, but when I asked them to name some favorite modules they were at a loss. Complete opposite of the module addiction you're describing here. | [reply] |
|
|
I have to agree that this directly reflects my own learning experience. When I started out with Perl, I was vaguely aware of CPAN but not familiar with its contents. As a result, my first programming ventures involved (amongst other things) handrolled templating systems, DIY date conversions, XML & HTML parsing with regexes, and many still worse horrors.
I view this now as no bad thing, since the shortcomings of my own solutions have allowed me to appreciate the complexity of the issues involved in these seemingly (to a beginner) simple tasks. When faced with a problem, I will now always look first to a module, since I understand the value of a tried and tested solution.
Surely it all comes down to the issue of abstraction. The essential benefit of a module is that you don't need to understand its internal workings in order to use it. For me there is no difference between using a module, and using Perl's built in 'sort' function versus writing my own - I don't need to concern myself with the underlying alogarithm in order to benefit from it. Of course, if I wanted to, I could look at the source code of either. But the point is I don't need to.
I see no problem in using an interface without worrying about its implementation. Is this not the entire philosophy of OO programming? And taken to its extreme, is this not the reason we all use Perl (or any other language) versus telling our computers what to do by constructing the correct sequence of '1's and '0's ...?
| [reply] |
Re: Modules, Frameworks, and Reinventing the Wheel
by johnnywang (Priest) on Aug 12, 2004 at 19:04 UTC
|
Personally I tend to (re)invent lots of wheels, but I also tend to throw away my invention when I do find a good module. The problem for me is that finding the correct module and making sure it does what I want is often a more daunting task than writing my own, especially at the beginning of the project when I don't even know what I really will need. I'm a fan of the Agile methodology, which usually means that at the beginning I only need something really simple to get the first working version. As I gradually understand the complexity of the problem, and thus the requirements, I can better judge whether a module will do what I need. At that time, I won't hesitate in using a good module.
So I'd say, invent and re-invent as you see fit, but be on a constant lookout for existing modules that actually do what you want. There are lots of smart people out there.
| [reply] |
Re: Modules, Frameworks, and Reinventing the Wheel
by water (Deacon) on Aug 13, 2004 at 12:59 UTC
|
modules ++
frivolous module use --
mom and apple pie ++
Seriously, we favor two kinds of modules --
-
objects -- with encapsulated data, public & private methods, and numerous unit tests,
- exported subroutines -- with complex behavior, no side effects, and numerous unit tests
In both case, wrapping it up a module allows cleaner code, easier refactoring, and better documentation.
Consider something like this
if (! &valid_foozle_input($wozzle)) {
versus
if ($wozzle =~ /extensive-perl-regexp-line-noise-here/ {
The former clearly indicates what is going on, the documention on what makes something fozzle_valid can go into the module (sub or object, depending), you can now write unit tests against the sub, you can use the sub in numerous places across the codebase (instead of just in this file, as a local sub would require), not have repeated code, etc.
just my two cents --
your mileage may vary
water from the great white north
| [reply]
[d/l]
[select] |
Re: Modules, Frameworks, and Reinventing the Wheel
by perlfan (Vicar) on Aug 13, 2004 at 18:09 UTC
|
I agree with the author, and I personally see this as a good reason for the "community" to put together some type of SDK.
CPAN is great and all, but quality assurance is its a major weakness. This is something that must be done on the community level, and if any one can do it, it is the Perl community...
| [reply] |
|
|
There have been many, many mile-long threads about this on the module-authors mailing list. Everyone agrees there is a problem, but noone really knows how to effectively address it, and of course, anything has yet to happen.
One thing that is always agreed in these discussions, though, is that there will never be barriers to entry on CPAN. The fact that there is no policing is one of the major reasons for CPAN's success (much as it may be causing problems in turn), and is not going to change, ever.
Makeshifts last the longest.
| [reply] |
|
|
CPAN shouldn't allow modules that have been reliably reported to be buggy or a security risk without being documented as such, but the same goes for any other website with a collection of scripts. If it's not core, it's just another script from someone's website.
| [reply] |
|
|
