The Problems of Perl: The Future of Bugzilla

Raj Gupta gupta at zeesource.net
Sat May 12 01:22:08 UTC 2007


I also want to add my 0.02 in this discussion.

Several organizations customize and change Bugzilla code to suit  
their requirements. We have done some such changes for our clients.  
This is one of the big advantages of Open Source projects--you can  
customize and change code to suit your situation.

Currently, such changes are relatively easily folded in to newer  
versions of Bugzilla, as the language and framework of Bugzilla  
remains fairly stable.

In case the language and framework is changed, think of how many  
organizations may be stuck with the versions that they have, unless  
they make major re-investments in changing code in the new language!

Regards

Raj


On May 11, 2007, at 12:06 PM, Myk Melez wrote:

> 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 does it) and then see if there's any way to use that to  
> support incremental reimplementation.
>
> -myk
>



  --
  Raj Gupta                          gupta at zeesource.net
  1684 Nightingale Avenue     Suite 201
  Sunnyvale, CA 94087            408-733-2737(fax)

                      http://www.zeesource.net





More information about the developers mailing list