The Problems of Perl: The Future of Bugzilla
wicked at etlicon.fi
Thu May 3 11:47:27 UTC 2007
On 03.05.2007 03:30, Max Kanat-Alexander wrote:
> * Reviewing Perl code takes much longer than reviewing other
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
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
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
> 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.
"Anything is possible. It's all about probabilities."
More information about the developers