To me, Perl is like a good book. It's a good quick read that takes you in
quickly and entertains you without wasting your time. But you can also go
back and re-read it again and again, and each time you re-examine it you
find another level of depth and complexity.

As a programming language, it is a quick and dirty scripting tool... "shell
scripting on steroids". Using it for larger projects with a single
implementor requires experience and wisdom. Using Perl for a large project
with multiple-coders adds the requirement for discipline. The mantras for
wisdom and discipline are there... but you actually have to go looking for
them.

Where should Perl be going?

"There is more than one way..." IMHO should apply to people who code in
Perl, not the core Perl modules, i.e. Perl Library. Part of the reason I
believe there is validity to the claim that Perl is too complex, is that
there isn't really any standard API or naming conventions in the core
modules. GBARR is pretty hot on this issue, and I hope he gets a
perl6-library working group and mailing list setup soon. I think the whole
of core Perl modules needs to be tossed in the wash.

It'd be nice if taint, strict, and other "bondage and discipline" coding
practices were things you had to turn off, instead of automatically on. That
would give the casual coder a beaten path from which they could chose to
depart in whole or incrementally.

I'd don't think Perl will really be accepted as a real programming language
until it has a formal specification. People say you can't write an LL or
LALR grammar for Perl, but others have mentioned ANTLR
(http://www.antlr.org/) which is LL(k). ANSI Perl may sound like an
oxymoron... but one can still hope.

Garrett




 

Reply via email to