The Problems of Perl: The Future of Bugzilla
aaron.trevena at gmail.com
Sat May 12 10:08:02 UTC 2007
On 11/05/07, Myk Melez <myk at mozilla.org> 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.
User's don't care about what language is used, developers, rightly,
tend to stick to languages they know and like, hardly a bad thing.
> 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.
That's funny because I'd wager I write more and know more about Perl
than either of you, and I disagree.
Max and your criticisms of Perl thus far have been entirely
subjective, looking at the pros and cons wiki page, it is pretty clear
that switching to Python or Ruby would bring very real technical
problems to the project, not to mention the social problems involved
in forking and alienating both users and developers.
> 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.
IME that isn't true. Mitigating for Python's poor error reporting,
Ruby's poor performance and or reinventing wheels in Ruby are 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).
That's nice for you. Like I said, your and max's feelings are purely
subjective, I think Python imposes a huge productivity tax, what with
linespace sensitivity and poor error reporting, but I know that's
mostly subjective and don't go badgering Python projects to switch to
perl, or trolling on slashdot/digg/reddit/etc as Python fanboys tend
If you'd been paying attention, you'd see that Perl 6 features have
been backported to Perl 5 both in CPAN and Core. Perl 5 is under very
active development - have you seen the changelogs for 5.10?
The next version of Perl is 5.10. It's a couple of weeks away. Perl 6
and Parrot development have been driving some recent development of
Perl 5 in not only CPAN space but also the compiler and language.
> 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.
Call me crazy, but how about focusing on using contempory Perl and
looking at genuine technical problems instead subjective 'grass is
After so many years I'm pretty surprised that none of the bugzilla
developers have worked on something to make bundling CPAN modules
easier, or even used anything like PAR - every wheel seems to be
I'm also surprised that there is no pagination for results, and that
every result for a query - even if there are thousands are always
fetched and loaded into tons of hashes - no wonder it's memory hungry
if you write code that eats memory like candy.
I spoke to Max about solving this latter problem, and I'm still
interested in doing so, but to be honest the combination of the
Mozilla Foundation/Corporation leaving the project to rot with no
funding or support, so much crufty out of date code and a couple of
vocal people clamouring to stop useful development and instead switch
to more fashionable languages makes me think "stuff it, it's easier to
use rt or trac than put up with that".
If anybody is actually interested in some constructive feedback on
what needs doing to improve the bugzilla project, that's fine, but I'm
not going to waste my time, when people who make money from bugzilla
are wasting there's rewriting it poorly in a language that makes them
feel warm and fuzzy.
LAMP System Integration, Development and Hosting
More information about the developers