The Problems of Perl: The Future of Bugzilla

[Gervase Markham]

It's taken me a while to read and think about this; apologies for that.

Max Kanat-Alexander wrote:
>   * Reviewing Perl code takes much longer than reviewing other
> languages. 

I don't agree. I find reviewing Perl takes much less time than reviewing
code in other languages. This is because I know Perl, so finding that
reviewing it is easier is not a surprise.

>     o There are many ways to do the same thing in Perl. It's even the
> motto: "There's More Than One Way To Do It." However, this means that
> each reviewer must enforce very strict code guidlines on each coder, or
> must learn each coder's coding style. In the interest of consistency,
> we usually pick the former. This takes more reviewer time. It's also
> frustrating for contributors who are used to writing in a particular
> fashion.

Can you cite recent examples of such frustrated contributors?

>     o More ways to write the same thing means there are many more *bad*
> ways to write code in Perl than there are in other languages. In any
> language it's *possible* to do stupid things and not realize it. In
> Perl it's easy. Or even when the code does what you mean it to, just
> because it *works* doesn't mean it's good. My experience is that Perl
> encourages people to write code that "just works," but might not be
> architected appropriately. Once again, this is possible in any
> language, but I think Perl makes it easier than other languages to
> write bad code.

Can you cite recent examples of code submissions of poor quality? Do you
really think we would get fewer poor quality submissions if Bugzilla was
written in Python?

Poor quality code is caused by writing things too quickly and focussed
only on your own needs. This is not a language-specific problem.

>     o It's very easy to make Perl code hard to read. It uses strange
> variables like $_. It relies heavily on complex regular expressions. I
> don't think anybody would argue that Perl *encourages* readability.

If you don't like that, let's "use English;". It would be the work of a
couple of hours to convert the codebase, should we choose.

But again, name examples of when this has been a problem.

>   * Perl lacks many of the features that implement what computer
> scientists call "design by contract." That is, Perl doesn't enforce
> things. For example, Perl doesn't check the type of arguments to
> subroutines. You can't make subroutines private in a class. Programmers
> have to actually read the documentation to know that a function is
> really "private" or "protected." 

Examples of bad patches which erroneously used internal functions?

To summarise the above: you say that Perl has all these disadvantages in
terms of gaining contributors and patch quality. Do you have any
evidence to support these assertions?

>   * Perl lacks a real exception mechanism. We would have to write our
> own if we want one.

Do we? I think we manage fine without. Web applications seem suited to
our Throw*Error-style error handling.

>   * Under mod_perl, because of the design of Perl, Apache processes
> grow HUGE in size. We kill them if they get up to 70MB, but even 40MB
> for a single Apache process is too big. The fact that Perl never
> releases memory back to the kernel is a problem.

I believe you already had suggestions and offers of help to deal with
this issue from mod_perl hackers on your blog.

>   Since 1998 there have been many advances in programming languages.
> PHP has decent object-oriented features, python has many libraries and
> excellent syntax, Java has matured a lot, and Ruby is coming up in the
> world quickly.

Right. But I don't see any of them being so much better than Perl that a
rewrite would be a net gain.

>   Nowadays, almost all of our competitors have one advantage: they are
> not written in perl. They can actually develop features more quickly
> than we can, not because of the number of contributors they have, but
> because the language they're using allows it. There are at least two
> bug-trackers that I can think of off the top of my head that didn't
> even *exist* in 1998 and were developed rapidly up to a point where
> they could compete with Bugzilla.

Then why don't we/you stop work on Bugzilla and go and work on those? If
they are already competitive, it surely makes more sense to enhance what
already exists.

>   But still, any of you long-term contributors to Bugzilla who also
> have experience in other languages, ask yourself this question: "In all
> the time I've spent working on Bugzilla in Perl, how far could I have
> gotten on writing another bug tracker, from SCRATCH, in another
> language?" My personal estimate is that I could have entirely
> re-written Bugzilla in Python or Ruby in half the time I've been
> working on it in Perl. (That would be re-writing it in a year and a
> half, not an unreasonable amount of time for 80,000 lines of code or
> so.)

80,000 lines of debugged, production-quality code in a man year and a
half? That's way, way outside normal metrics.

Think about it, though: a man year and a half or more of work - unpaid
work - just to stand still. Any business which did that would go under.
Say it made adding features and fixing bugs after that time twice as
quick (a generous estimate). We'd have to do another man year and a half
of unpaid work before it got to the stage where we were better off than
if we had stuck with Perl. The numbers here suck.

>   One advantage that Perl has is CPAN. There are a lot of libraries
> available. But then again, that's also a problem that Perl has--people
> need to install SO MANY modules just to use Bugzilla. Witness all the
> protesting there is from our users whenever we add new required modules
> to Bugzilla, and the support questions we get about problems with CPAN.
> 
>   And even that advantage is fading. There are a lot of python modules
> available now. Java has Jakarta and a lot of other modules. And Ruby
> has RubyGems, which are even easier to install than CPAN modules. PHP
> has PEAR, which is also very nice.

Requiring lots of modules is either a good thing or a bad thing. Decide! :-)

>   In 1998, Perl was the right choice for a language to re-write
> Bugzilla in. In 2007, though, having worked with Perl extensively for
> years on the Bugzilla project, I'd say the language itself is our
> greatest hinderance.

I don't agree. I think lack of developer time is our greatest hindrance.

I also think that Bugzilla is a mature application. Other bug trackers
have fast development partly because they don't have all the features we
do yet.

>   1) Figure out a way to re-write *parts* of Bugzilla in another
> language without affecting performance or greatly adding to the
> complexity of installation. We could then incrementally move to another
> language.

...and make it twice as hard to install for the intermediate period. :-)

>   2) Work on both projects at once--a small team working on the
> re-write in another language, and the same team we have now working on
> the current Perl version, up until version 3.4 or 3.6.

If you want to go and do this, I can't stop you :-) It's free software.
But here's an alternative scenario. We continue working on Bugzilla in
Perl. If and when no-one is using it any more because there are better
alternatives, and/or there is no-one interested in developing it any
more, we stop, and the world continues to revolve, and free software
development continues using another tool or tools. Bugzilla enters the
Software Hall of Fame.

If you want a bug-tracker in Language X, go write one in Language X or
work on one of the existing ones in Language X. Or, if you really think
it's the best way forward, fork Bugzilla and incrementally rewrite it in
Language X, with whoever you can persuade to help. But I would be very
much against the Bugzilla project making this a main or even a supported
line of development.

Of course, my viewpoint needs to be weighed taking into account the
level of my contributions recently.

Gerv