[sf-perl] "Perl Needs Better Tools" by Matisse Enzer
doom at kzsu.stanford.edu
Mon Aug 29 15:18:37 PDT 2005
Chris Palmer <chris at noncombatant.org> wrote:
> Rule #1: Real Engineers Don't Blame Their Tools.
> 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.
Perl is not the best language for everything, but it might get there
someday. Perl's domain has already expanded much further than anyone
would've expected. Things like this happens because perl programmers
get interested in making it happen. Even for someone who's conversant
with multiple languages there's a cost associated with context switching
between them: it's a good thing if you can reduce these.
Myself, I tend to get driven up the wall by people taking the line "use
the right tool for the job", but that's perhaps a rant for another day.
> 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).
My contention would be that automating simple tasks is generally
a good thing, and that on occasion you get a "synergetic reaction",
if you'll forgive the expression; where simple little things add up to
one much greater thing (consider ftp vs. http).
> 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.
You mean like the perl debugger?
More information about the SanFrancisco-pm