[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 06:40:49PM -0600, John Goerzen wrote:
> 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.

Yes... it... does. You... write... bad... perl... that's... all.

> 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.

I have never seen this form of argument in any scenario which was not
backed up solely by defining "kludgy and fragile" as "that way",
without justifying why it might be a bad idea.

It usually just means "I've decided what the answer will be and am now
going to make the scenario fit that answer".

> 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
> 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.

That means you're not a good perl programmer. That's all it means. In
fact, it's a good definition of "bad $language programmer".

What I think you meant to say is:

For a short program that does a great deal of parsing, just reading
from stdin and writing out, a *bad* Perl programmer will be able to
whip it out quicker than a good Python programmer.

Which is probably still true.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature


Reply to: