2 Qs XML(loosly) and reinventing the wheel

[Curtis Poe]

----- Original Message -----
From: "E J" <moiraine at qwest.net>
> Second Question:
> Reinventing the wheel is one of those concepts that is rough to define
> isn't it?  That's not the question, but you can answer if you want...of
> course, I can't stop you because if you're reading this you have a copy
> on your computer and you can do anything you want on your
> comptuer...where was I?  That's not the question either.
> When is it reinventing the wheel?

I'm at work and don't have a lot of time, but I want to take a moment to
address this issue.

> The first step type, use strict, save,
> run, clean up all errors...hehe.  Another thing I've noticed is that
> delving into someone else's code has helped me learn a fair amount.  Get
> an alternative perspective.  I guess the code isn't all that ugly
> realy...I'm just used to use strict.

Good for you!  Damian Conway gets away with not using strict.  Mark-Jason
Dominus gets away with not using strict (he actually has stated that it's
over-rated).  Many people would even be surprised to discover that CGI.pm
does not use strict.

Unless a programmer can legitimately claim to be on par with them, they
should probably be using strict.  Oh, I'm not saying for a one-liner or a
throw-away script to analyze logs must have strict.  I'm talking about real
programs that are likely to be re-used.

Let's take Damian Conway's code.  He has stated that he tends not to make
the types of errors that strict guards against and much of his code would be
inhibited by strict.  He often doesn't want strict references, for example.
Most of his code would work just fine if you tossed 'use strict' at the top
(and turning it off in the scope where he abuses this feature).  However,
when was the last time you installed a Conway module without copious tests?
If a programmer comes to me with code that really, really needs strict
turned off in several places and has a reasonable test suite in places to
guard against problems that "use strict" will catch, I won't be worried as
much about not using this pragma.  Anyone else is probably going to fail my
code review.  "strict" lets us guard against failure in subtle ways that
those who fail to use strict usually don't appreciate.

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 :)

> 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 :)

As for reinventing wheels, let's consider the classic reinvention:  CGI.pm.
Why do most people reinvent this?

1.  It's bloated.
2.  They won't "learn" CGI if they use the module.
3.  CGI.pm syntax seems intimidating to some people.

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:

1.  It's bloated (then use CGI::Lite)
2.  Tries to cater to too many "needs" and thus confuses people (read the
docs for how many ways you can call CGI::param())
3.  It doesn't use strict (many disagree with this reason)
4.  Excessive use of globals make maintenance difficult

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.

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.

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.  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.

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.

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

=====
"Ovid" on http://www.perlmonks.org/
Someone asked me how to count to 10 in Perl:
push at A,$_ for reverse q.e...q.n.;for(@A){$_=unpack(q|c|,$_);@a=split//;
shift at a;shift at a if $a[$[]eq$[;$_=join q||, at a};print $_,$/for reverse @A

TIMTOWTDI