The Problems of Perl: The Future of Bugzilla

[Teemu Mannermaa]

On 03.05.2007 03:30, Max Kanat-Alexander wrote:
>   * Reviewing Perl code takes much longer than reviewing other
> languages.

At least for me, that's not true. If I would suddenly get a PHP, Python 
or even, sick, a Ruby review request it would probably take up to 1 year 
to get into speed. Why? Because I would have to learn the language 
first. Just like I had to learn Perl back when I was starting to use 
Bugzilla.

Besides, for my review most time goes into looking that the code 
actually does what it's supposed to do. I do this by testing changed 
features and not just by looking at the code. Only small fraction of 
time goes into making sure our style guide rules are met. Usually this 
can be done by comparing the look of the code to surrounding code. Rest 
is done with automated tests.

If anything, we should extend these automated tests to catch more things 
we want to enforce.

> 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.

This could be why patches from known contributors seems to be more easy 
to review and accept. Or maybe they just don't know yet what objects, 
utility subroutines, filters and other ready-made items we already have 
and tend to "reinvent the wheel". If it's the latter then I don't think 
switching language helps at all. You have to learn these things for each 
project no matter what language they are written in.

I don't know what patch writers think about our rules. For me that's not 
a problem as I don't know any other way. :) Besides, I thought they are 
based on globally accepted Style Guide of Perl.

>     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

True, but I don't think we have used much those strange variables. Isn't 
there supposed to be way to write Perl without using them?

> don't think anybody would argue that Perl *encourages* readability.

Sure, it can have nasty structures that you have never seen before. You 
can't read a language that you don't know. This applies to every language.

>   * Without some experience, it can be difficult to read Perl's
> compiler error messages and actually then determine what's wrong.

I don't think any error message makes any sense if you don't know how 
things work.

> has RubyGems, which are even easier to install than CPAN modules. PHP
> has PEAR, which is also very nice.

Big question for me is not how easy they are to install myself but 
rather if there are packages available for them in my platform. Okay, 
having RPMs makes them very easy to install but it also gets me security 
updates. I don't want to follow each and every module myself to know 
when they have a security update out there that I need to install.
-- 
Teemu Mannermaa
System Specialist

"Anything is possible. It's all about probabilities."