Slash Boxes
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.
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, as he suggests, but in good Perl rather than some other language that will require bridging.
    • If they don't enforce coding standards now; then any language they do choose is not going to help. Python has the "whitespace" thing but if you don't have standards you still get a wide array of coding practices. Ruby gives you nothing more than Perl as far as maintaining style.
      • Yeah, but Perl is line-noisy! And it has regular expressions! And it gives you many ways to do things! It’s even the language motto, “TMTOWTDI”! Whereas Ruby’s motto is “optimise for programmer happiness” or something like that! Asdfghjkl!!1


    • 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 [].
        • 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 m

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