The Problems of Perl: The Future of Bugzilla

[Christopher Hicks]

On Wed, May 02, 2007 at 05:30:00PM -0700, Max Kanat-Alexander wrote:
>   So the popularity argument is dead.

It sure is.  For some of us, it was dead from the gitgo because its usually falacious, misinformed, and irrelevant.  Considering PHP sems to fall into this same area - why use a knock-off of Perl that's been far buggier and security-hole-prone than anything except for sendmail and Microsoft?  If its not because all the other kids are doing it, its hard to believe its because PHP is good.  If you're going to steal from Perl, why not keep say dynamic linking and DBI.  It would have made the whole thing much less nasty.  Those are questions of vision and architecture which PHP totally blew.  What are they going to screw up next?

If you're insistent on rewriting bugzilla, do it, but not doing it in Perl seems petty and reactionary.  I won't run a non-Perl version of bugzilla if that's what happens down the road.  I'll rewrite bugzilla in catalyst first.

Bugzilla's problems are architectural, not language.  There are plenty of techniques (like Perl::Critic and perltidy) to address your concerns.  As many have said, spaghetti code can be written in any language.  Looking at most PHP projects this is self-evident.  Thinking about an architecture is necessary regardless of whether you stick with Perl or not.  If you had a Perl app in that architecture wouldn't most of your frustrations diminish?

And finally, if you can't handle Perl's flexibility, go back to the side of the circus with all the silly nets and things.  We have nets too, but we try to only pull them out when they're NEEDED.

-- 
</chris>

"Are your girl scout cookies made with real girl scouts?" -- Wednesday Adams