[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python or Perl for a Debian maintainance project?

On Thu, Feb 19, 2004 at 09:29:20PM +0000, Will Newton wrote:
> On Thursday 19 Feb 2004 8:22 pm, Andrew Suffield wrote:
> > All well-written perl is like this. If it's not clean and precise then
> > it's bad perl. The fact that there is a lot of bad perl around does
> > not affect this.
> In my experience it is not so much that there is bad Perl, which there is, but 
> that Perl doesn't seem to scale to large teams. The "there's more than one 
> way to do it" idea hurts in big teams, you have to pick one way and stick to 
> it, or you get a hairball of conflicting styles. This is a problem with any 
> language, but Perl's idiosyncratic and extremely flexible syntax seems to 
> exascerbate the problem.

This is precisely the point and precisely why I switched from a huge
Perl fan to a huge Python fan.  (And, incidentally, why I am probably
going to switch from Python to OCaml or Ruby before too long...)

Perl... does... not... scale.

If you google, you can probably find me making the argument that Perl
should not be judged by the bad code that some morons write.  And that
is entirely true, and it applies to any language.  There is good Perl
out there.  I've used some of it.

Perl's problem is not just There's More Than One Way To Do It, vs.
Python's "there's one right way to do it".  It's also that the way of
doing some things -- *especially* OOP things -- are kludgy and fragile.
That is exactly the wrong thing to have when you're trying to make your
code more bulletproof by splitting it into nice objects :-)

I have never learned awk and only a little of sed.  Perl always served
my needs for the sorts of things others would use those for.

What it boils down to is: use the right tool for the task.

You can probably make *any* reasonable tool work for any task, but the
question is, at what cost?

For a short program that does a great deal of parsing, just reading from
stdin and writing out, a good Perl programmer will be able to whip it
out quicker than a good Python programmer.  For a larger application
with complex interactions, a good Python programmer will likely be able
to whip it out in about the same amount of time as the Perl programmer
-- but will easily beat the Perl programmer when it comes time to
maintain or enhance it, and probably have fewer bugs to start with.  I
have personal experience with this, having written both types of
applications in both languages.

It is possible to write bug-free code in Perl and to write quick 'n'
dirty parsers in Python.  It's just not optimal to do so.

I see Python as the all-around winner.  I like to pick one language and
use it for most of my development (to boost code reuse potential), so
these days I use very little Perl, since the extra time I spend coding
parsers in Python more than makes up for itself when I wind up finding
out that I need to drop that into the big app du jour a month later.

-- John

Reply to: