2 Qs XML(loosly) and reinventing the wheel

E J moiraine at qwest.net
Fri Feb 15 12:05:32 CST 2002


Curtis Poe wrote:

> 
> So, that being blathered, you're absolutely correct to want to get that code
> to run under strict.  Some can avoid strict for good reasons.  Most who
> avoid strict are PRECISELY THE PROGRAMMERS WHO SHOULD BE USING IT.  Pardon
> my shouting :)

I totally understand.  The programmer for the script/app in question is 
definately on use should use it.  Especially, since I'm running it under 
mod_perl.  Well, the origional script is regular cgi, but the new and 
improved I'm working on is mod_perl. Of course, after I typed this, I 
decided to make it work under regular cgi, first, then deal with 
mod_perl probs...

> 
>>Ok...back to the question.
>>Delving has taken a little while already.  Should I wade through more
>>forum apps trying to find another one I like, or should I continue to
>>play with the code?
>>
> 
> That's purely a matter of personal choice.  If this was a business decision,
> you'd have to look at how cost-effective it is.  If it's a personal
> decision, you have to decide how much you value your free time :)

It's kinda' both.  I have Ikonboard, but it's not threaded.

> As for reinventing wheels, let's consider the classic reinvention:  CGI.pm.
> Why do most people reinvent this?
> 
> 1.  It's bloated.
use CGI qw(:standard)
or
use CGI qw(:html)

> 2.  They won't "learn" CGI if they use the module.

yah...what.e.ver.

> 3.  CGI.pm syntax seems intimidating to some people.

perldoc perltoot

;-)

> Well, the first reason is valid.  The other two are bogus, but rather than
> repeat again what I've said many times before, I'll skip to the real reasons
> someone might want to rewrite CGI.pm:

hehe.

> 1.  It's bloated (then use CGI::Lite)
or that, too.

> 2.  Tries to cater to too many "needs" and thus confuses people (read the
> docs for how many ways you can call CGI::param())

Eh...understandable.  I'm still not quite getting XML...I am, but not.

> 3.  It doesn't use strict (many disagree with this reason)
Yes, but it's still more secure than plain cgi.

> 4.  Excessive use of globals make maintenance difficult
that's what perl -d is for...hehe

> 
> I know of one (and only one) programmer who is working on a new CGI parsing
> module who is addressing some of these issues and addressing them
> *correctly*.  We disagreed on the problem with globals, but he wants it
> backwards compatible and who am I to argue?  Aside from this programmer,
> I've had a standing bet with CGI programmers that if they have written their
> own implementation, I'll find a minimum of 5 bugs or limitations.  I usually
> find many more.

I wouldn't doubt it.  Despite the various printing features, there's all 
the html packing and unpacking, proper header format with nothing more 
than print header(), file uploading handeling.  All sorts of nifty stuff 
one doesn't think of when trying to rebuild it.  The script I'm 
rewriting doesn't use CGI.pm at all, so builds a global %QUERY hash that 
contains...the query.  A subroutine about 10-20 lines long is called 
each time the script is run to parse the queary string and put it in 
%QUERY.  When, the whole time he coulda just said my $name = 
$q->param('name'); or whatever.  And gotten rid of the hash and the 
subroutine.

I don't doubt for a minute you'd find bugs.

> That means that people who reinvent wheels are usually people who don't have
> enough Perl skill to do so adequately.  Wheels should be reinvented to make
> better wheels, not different ones.  Most wheels should be added to, not
> rewritten.  This includes many modules on the CPAN.

Yup.


> Discussion board software downloaded from the 'net does not usually qualify
> as a "wheel", however :)  (In fact, I almost vetoed using Bugzilla here at
> work due to the pitiful code quality and its reliance on MySQL.  However, it
> was free and easy to install, so we used it.)  If you have the desire to
> clean up the code, that's great.  

Groovey...just making sure. :-)

> I object, for example, to anyone using
> anything from Matt's Script Archive.  Even though he has managed to get most
> of the bugs and security holes out of his code, the code quality is simply
> awful.  We Perl programmers have a bad enough rap without using/spreading
> bad code.

My fiance, who's JAPH, says the same thing.  I ran across it, but didn't 
download anything, thank [+ $diety +].


> Summary of above rant:  reinventing should be for improvement, not just
> change for change's sake.  Most of the heavily used CPAN modules should not
> be reinvented without an excellent reason.  Poorly written stuff, such as
> discussion boards, that others are not overly reliant on is another story.

:-)  yay

> Hmm... I guess I had more time than I thought!

Yeah...I know what u mean.

Elizabeth

---
gotta get this sig up and show off my Perl Geek Code

TIMTOWTDI



More information about the Pdx-pm-list mailing list