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://u
se.perl.org/~chromatic/journal/33191
--
Guillaume Rousse
Moyen Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
-
To view or change your list settings, click here:
<http:
//bugzilla.org/cgi-bin/mj_wwwusr?user=bond yahoo.com>
|
