[Tutor] Are you allowed to shoot camels? [kinda OT]

[Alan Gauld]

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