Alan, We'll just have to have to disagree about awk. I starting learning Perl to avoid learning awk :-)
I also disagree about the symbology. I am never confused by it. In fact, I find it clarifies the language although I agree its ugly. When I see a random variable in Perl I can tell at a glance whether it's a scalar, list, or hash. That isn't true in Python (or most other languages). I realize that doesn't mean much in large OOP programs but in medium to large single-purpose scripts it does simplify debugging and maintenance. Jeff -----Original Message----- From: Alan Gauld [mailto:[EMAIL PROTECTED] Sent: Thursday, February 03, 2005 5:14 PM To: [EMAIL PROTECTED]; Smith, Jeff Cc: tutor@python.org; [EMAIL PROTECTED] Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT] > > For the non-Perl people here, let me defend Perl by saying it is > > VERY good at what it was built for and not so good (but passable) at > > what it was not built for. > > > > What it is good at: > > Very rapid development of small scripts > > Replacing sed/awk/ksh/etc for scripting > > Manipulating strings > > System administration tasks Absolutely true and the reason I used Perl for several years before I used Python - even though I was aware of Python and had even fired up the interpreter a couple of times. But then I had the advantage of using C and C++ and Pascal(Delphi) and Lisp and Smalltalk for more complex programs. And I still used awk because Perl makes a lousy awk replacement! But as a shell replacement its great, and for string manipulation only Snoball beats it. The only reason I initially took Python seriously was as a teaching language for my tutorial, but once I got into it I realised it was a lot more powerful than I had originally thought. > > What it is only passable at > > Large scale team development > > OOP Passable is optimistic, I used Perl with a team of only 6 programmers and it was a disaster! > > Most of what Python developmers complain about in Perl are aimed at > > the rapid development thing. Perl is very terse which allows you do > > quickly script up small filters and data miners. I still use Perl > > for this and don't think that will ever change. Absolutely and I agree. The things I don't like are not the rapid development things, the $,@ symbology is completely unnecessary and is extremely counter intuitive even for experienced Perl coders. We still have arguments about references versus scalars etc yet after 10 years of using Perl in prodsuction code... It was a side effct of shell programming that should never have happened (although I will grant it yields a marginal speed increase by improving optimisation in the compiler!) > > Someone also complained about the "many way to exit" issue. > > Personally, I love that and use it to clarify my code. On a normal > > if statement I will put the test first: And for one person projects, where a consistent style is used its fine, but the minute you get beyond small projects its another complication waiting to bite. But again thats Perls background showing through. Python was never intended just for quick n dirty scripting it was from the outset designed as a general purpose language so embodied "best practice" - or Guidos take on that - as discovered by computer science research. Larry Wall simply created a language to do a job, it turned out to be powerful and got used a lot more than he expected! There is no perfect language, and very few truly bad languages - they never get out of the lab - they all have something that they are good at and from which we can learn! Alan G. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
