[sf-perl] "Perl Needs Better Tools" by Matisse Enzer

[Chris Palmer]

Rule #1: Real Engineers Don't Blame Their Tools.

Every programming language that survives the culling period is good for
the purpose it was designed, at least. If it's good for anything else,
that's just a bonus. Perl was designed to help sys admins chew up log
files and pretty-print them, and to do other sys adminly tasks for which
the shell is too tedious or slow. Perl is superlative for this task.

Similarly, Java is ideal for keeping armies of semi-competent
programmers employed and for forcing hardware upgrades; C is a wonderful
high-level assembly language for writing operating systems; Python would
indeed have made a better shell; and so on. It's to their designers'
credit that these languages are so well suited to their tasks, but of
course the price of that perfection is that the languages are not too
great for other tasks.

For those cases where a language is used for a task other than its
primary intended task, see Rule #1. Adherence to Rule #1 explains why
Perl is often used for largish projects outside its original domain, why
we still see applications with GUIs written in C, and so on.

A spiffy IDE to replace my four xterms might help some people or might
not. See Rule #1. It's such a minor and religious issue that I tend to
ignore and abhor it (respectively).

Adopting the trappings of Java (such as Eclipse, n-tier behemoth
designs, et c.) will not help Perl improve its marketshare. That might
not even be a worthwhile goal -- I don't want to use Perl for large GUI
apps any more than I want to use Java for boot scripts.

Perl is what it is, and it is awesome. It is not the best language for
all tasks, and if you try to force it to be, you are a silly person and
I shall taunt you a second time.

Rule #2: Every language must have an interactive interpreter, or it
sucks (but see Rule #1). If you're going to make a new tool to improve
Perl development, do that.