Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!jato!lwall
From: lwall@jato.Jpl.Nasa.Gov (Larry Wall)
Newsgroups: alt.sources.d
Subject: Re: uutraffic report (in perl)
Message-ID: <2256@jato.Jpl.Nasa.Gov>
Date: 23 Nov 89 00:46:57 GMT
References: <4025@mhres.mh.nl> <1194@radius.UUCP> <3273@convex.UUCP> <RICHARDT.89Nov21141554@anableps.berkeley.edu> <14946@bfmny0.UU.NET> <JGREELY.89Nov21190844@oz.cis.ohio-state.edu> <14947@bfmny0.UU.NET>
Reply-To: lwall@jpl-devvax.Jpl.Nasa.Gov (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 57

In article <14947@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
: Perl attempts to win converts like Crocodile Dundee (naaooww, THAT's not
: a Swiss Army knife, THIS <swish> is a Swiss Army knife...) at the
: expense of compactness.  It's a worthy idea, but there are drawbacks.

Heh, heh.  In Unix World they just called it a Swiss Army Chainsaw.
I kinda like that.

: On System V/386, for instance, with all debugging #undef'd and with -O
: turned on, the latest perl executable *after* both 'strip' and 'mcs -d'
: subtends 229K, and takes ~5 seconds to load, compile and interpret an
: in-line script consisting of 'exit 0;'.

This says more about the OS than perl, I fear.  On a measly 68020 here
with a load average of over 2, the same program takes 0.0 user, 0.1 system
and 0:00 elapsed time (rounded to the nearest second).  I suspect that
as soon as most everyone gets System V.4 and demand paging, this argument
will not be so potent.

In general, however, I agree with you that religious zealotry does little
good.  Enthusiasm is one thing--I'm a wee bit enthusiastic about perl
myself, for some reason--but I don't like to see people picking fights.
It makes people think either/or when they should be thinking both/and.

: For overnight batch reports
: this is irrelevant, but there's little hope of using perl as a quickie
: tool to get something fun done in, say, a hacked Pnews as one might with
: sed.  The perl answer, unfortunately, is "so what, just rewrite Pnews
: in perl" but this illustrates the "hump" of acceptance.  "Switch over
: completely or suffer inconvenience" does *not* cut to the heart of the
: UNIX philosophy.  It is closer to the religious passions that retard
: UNIX than it is to UNIX strengths.

<enter quibble mode>

s/The perl answer/Some people's answer/ || warn "Larry is unhappy.\n";

If perl is saying "so what, just rewrite Pnews in perl" and "Switch over
completely or suffer inconvenience", then it's not the perl I know.
The perl I know reads from stdin and writes to stdout just like any
other filter, and it encourages you to write incoming and outgoing
pipelines of other unix tools.  It even lets you feed multiple pipelines
simultaneously and close them down in any order.  Not even the C library's
popen() lets you do that.

<exit quibble mode>

Anyway, folks, just because something CAN be done in perl doesn't mean it
SHOULD be done in perl.  Likewise for shell, awk, C, etc.

Perl is just one more option.  Use when reasonable.  Your definition of
reasonable is probably different from the next guy's.  My definition of
reasonable says you should at least make it available on your system
sometime within the next two years.  Your mileage may vary.

Larry Wall
lwall@jpl-devvax.jpl.nasa.gov