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
-
To view or change your list settings, click here:
<http:
//bugzilla.org/cgi-bin/mj_wwwusr?user=bond yahoo.com>
|
