Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Why Port Bugzilla Away from Perl? 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Having hacking on Bugzilla a fair bit, I find it hard to take seriously the idea that Perl is what's wrong with Bugzilla development.

    Their codebase is a mess because they lack enforced coding standards. The poster seems to indicate that he thinks this won't be a problem with other languages. Maybe it's significantly easier to maintain a single style of coding in Python or Ruby, but it's sure not just a given. I've also worked on my share of horrible Python or Ruby.

    Why not just rewrite parts of the system
    --
    rjbs
    • Actually, nowadays we have pretty strict enforced coding standards: We did lack them in the past, though, it's true. I'd have less trouble if I hadn't been spending the last three years slowly and painfully refactoring all of Bugzilla. -Max
      • They're here: Bugzilla Developer's Guide [bugzilla.org].

        • That's a good start, but it focuses on design in the small. That's not a bad thing. Design in the small is very important. Design in the large is also very important, and there's no substitute for good taste (which often comes from bad experiences).

          I have the strong, armchair impression that design in the large is your biggest issue right now. Rewriting (or refactoring) is the cure. Porting to another language may seem like it helps, but in my experience getting rid of accumulated technical debt is more important.

          Switching away from Perl may be the right choice for other reasons, but the language itself has sufficient abstraction and power that I'm not aware of any design-in-the-large problems it suffers. I could give you a long list for C and PHP and to some extent C++ and Java.

          • Yeah. We've actually been working on design in the large for quite some time now--I've been largely spearheading the refactoring effort. It's kind of hard to describe those principles in something like a Developer's Guide, so that's why they're not there. (Except in the sense of the General Guidelines.)

            It's true that Perl is powerful enough to implement the design-in-the-large features we need. There may be other good reasons to switch to another language or framework, though.

            The primary reason I posted the
            • We're going to do some prototyping in various languages...

              I think your time would be better spent reading Conway's Perl Best Practices book and getting familiar with running your code through Perl::Critic rather than attempting prototypes in other languages.

            • It's true that Perl is powerful enough to implement the design-in-the-large features we need. There may be other good reasons to switch to another language or framework, though.

              Certainly true. If you have expertise with a particular language or framework and your switching costs are less than the cost of refactoring in Perl, it's clearly a good change, and rational people will understand that.

              I just hate to see important choices like this made on the basis of language advocacy, and your initial post

              • Yeah. That's exactly what I'm trying to evaluate, if the switching costs would be less than the cost of refactoring and then future maintenance. :-)

                And thank you, I'm glad we worked that out. :-)

                -Max
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.