The Problems of Perl: The Future of Bugzilla

[Myk Melez]

Folks seem to generally want to stick with Perl, which is not surprising 
given that Perl-friendly programmers are more likely to be attracted to 
a Perl-based project.

But I'll throw in my .02 and say that I think Max is right about the 
language.  Although it has many features to commend it and some elegant 
design, it also burdens programmers with overcomplicated syntax and 
provides too much enticement to poor programming practice.

Of course it's possible to write good Perl code (and bad code in other 
languages), and one can always mitigate some of the problems with style 
guides, review, etc., but those mitigations are themselves costly.

Either way, Perl imposes a productivity tax, and I'm much happier these 
days programming in other languages that have taken advantage of the 
last dozen or so years of research into language design (as Perl is 
still struggling to do with its next version).

Nevertheless, it's still hard to decide to switch languages.  Rewrites 
are expensive and risky, and they often fail (cf. the original Bugzilla 
3.0).  Plus, developments like the growth in browser-based logic, 
third-party extensions, and API clients may make the difficulties of 
hacking the core code less significant.

So I'd first look for intermediate steps that would improve support for 
extending Bugzilla using other languages (perhaps the way Thrift 
<http://developers.facebook.com/thrift/> does it) and then see if 
there's any way to use that to support incremental reimplementation.

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070511/4eae5354/attachment.html>