The Problems of Perl: The Future of Bugzilla

[Guillaume Rousse]

Max Kanat-Alexander a écrit :
>     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.
Establish a standard perltidy configuration file. And use a dedicated
framework to impose your prefered style, such as Perl::Critic.

>     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.
You never used visual basic, with its magic ANY type, or other
beginners-oriented languages, do you ?

>     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.
It doesn't force you, at least. Being an advantage or an inconvenient is
a matter or taste.

>   * Perl lacks many of the features that implement what computer
> scientists call "design by contract."
Very few languages (eiffel, at least) really enforce design by contract.

> That is, Perl doesn't enforce
> things. For example, Perl doesn't check the type of arguments to
> subroutines.
As most (all ?) dynamically typed languages. Many modules allow you to
do it, tough (see Params::Validate, for instance).

> You can't make subroutines private in a class.
You can have anonymous or lexical subroutines references.

> Programmers
> have to actually read the documentation to know that a function is
> really "private" or "protected." Perl doesn't have real assertions.
> (The "assert" command in C, Python, Java, or various other languages.)
See Carp::Assert.

>     Perl's lack of enforcement is a nice feature for the casual
> programmer, but for the design of large applications, you want the
> programming langugae itself to do as much error-checking for you as
> possible, so that you don't have to write the error-checking yourself.
> 
>   * Perl lacks a real exception mechanism. We would have to write our
> own if we want one.
See Exception::Class.

[..]
>   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.
Well, bugzilla packages from linux distributions are installable with
one command only. By making bugzilla available on CPAN, as as RT is
already, for instance, you could also make it available with a single
command. You could even distribute it as a perl packages bundle. They
are lots of standard distribution models already adressing this
dependency issue. Current home-made bugzilla installation model, on the
other hand (such as providing CVS files), just encourage users to
manually install and upgrade their running system.

Some large perl software (catalyst, RT) draw half of CPAN as
dependencies. This doesn't prevent them to be widely used. Of course, if
you target typical windows users whose only experience of software
installation is click'n'run self-extractable installers, you'll get such
kind of protestation. It's up to you to decide between software
engineering practices, and unaware users popularity.

Many of the problem you're exposing here are valid. And as such, have
already been handled inside perl community. Maybe learning from this
community would help there ? I recommand reading 'Perl Best Practices',
by D. Conway, for instance. Or even joining some perl conference to
present bugzilla, and discuss those issues directly with people.

BTW, your post has also been discussed here:
http://use.perl.org/~chromatic/journal/33191
-- 
Guillaume Rousse
Moyen Informatiques - INRIA Futurs
Tel: 01 69 35 69 62