[74] in Back_Bay_LISA
To perl, or not to perl - now _there's_ a question
daemon@ATHENA.MIT.EDU (niemira.jim)
Thu Nov 19 13:44:54 1992
Date: Thu, 19 Nov 92 13:08:10 -0500
From: niemira@rooney.fstrf.org (niemira.jim)
To: bblisa@inset.com
Reply-To: niemira@fstrf.org
Well, I suppose it would depend on what you're doing:
For any task, it make sense to use tools suited for the task. However,
I often find that larger tasks require multiple scripts, or require the
aforementioned state information, not only between phases of single run, but
between runs as well. For the larger projects (and those that seem to just
keep getting bigger 8*)), I prefer something a little more feature-inclusive;
namely, perl. For me, having a single script with a single thread of output/
error messages, for instance, beats having multiple scripts on multiple
machines with multiple outputs, each with it's own quirks. It also wins in
those cases that need to run fast, but would need a bazillion subshells/pipe-
lines in one of the shells. But it's not the be-all and end-all of u**x tools;
there are obviously situations where it's considerably worse than some other
tool.
But, hey, this needn't be a holy war - we're not replacing any of the
tools. Part of the art of sysadmining is knowing which tool will best get the
job done. perl is in some cases, and is not in others. I see perl as another
tool - I use it by itself sometimes, and sometimes as part of a pipeline. It
doesn't have to go against the 'Unix philosophy', as long as the user under-
stands its pros and cons. But if some other tool works better, you'd be silly
not to use it instead.
| It breathes fire. -more- | Jim Niemira |
| It breathes fire. -more- | Senior SysOp, Frontier Sci | "So?"
| You are not happy. -more- | niemira@fstrf.org | -Worf
--
Send mail for the `bblisa' mailing list to `bblisa@inset.com'.
Mail administrative requests to `bblisa-request@inset.com'.
