uutraffic report (in perl)

[J Greely]

In article <14947 at bfmny0.UU.NET> tneff at bfmny0.UU.NET (Tom Neff) writes:
>In article <JGREELY.89Nov21190844 at oz.cis.ohio-state.edu> J Greely
> <jgreely at cis.ohio-state.edu> writes:
>>  ... And yes, it *is* a religious issue.  It cuts to the heart of the
>>Unix philosophy, performs a triple bypass, and gets some useful work
>>done while sh is still in the first set of backquotes.  Ever seen a
>>disk usage accounting system written in sh?  It's not a pretty sight.

>More to the point, ever seen one in awk?  Probably not, because although
>people may write 'em they don't get around.

Actually, I've seen several, only one of which was written here.  All
written in that peculiar combination of awk, sed, grep, join, sort,
and <insert shell here>, which is the approach you seem to imply is
better than using Perl.  Whatever for?  You can implement Life in a
spreadsheet, but do you really want to?

>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.

Huh?  I'll overlook the personification of the enemy for the moment,
and say that some Perl *users* do that.  Not at all important to me,
however.  I use Perl because it has the right combination of fast
programming time and good runtime performance.  Yes, I can write
filters in C, and even entire programs, but I can't write, compile,
[debug, compile, repeat] a C program faster.  For many tasks, fast
completion is more important than optimal runtime.

>It's a worthy idea, but there are drawbacks.  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;'.

...and my "hello world" program in C takes two minutes to compile, and
takes up 48K.  BFD.

>"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.

Am I right in suspecting that you didn't read my sentence the way I
wrote it?  I never said it epitomized the Unix philosophy, I said it
*ignored* it.

		"I know it's not Unix, but it's *convenient*"

>So while I like and admire Perl and feel it's the best batched report
>writer invented, I think its limitations preclude basic tool status.

"basic tool status"?  So it shouldn't be sold at Sears?  If I have to
go to a hardware store to pick it up, that's fine with me.  If
hobbyists don't need it, they don't even need to know it's there.  How
many normal users know how to use "join" (or, for that matter,
"find")?

>Perhaps one solution would be to stop writing '?2p' translators for a
>bit and write 'p2c' so that cherished perl tools can be C-compiled
>for lasting freshness.  Then perl becomes a superb prototyper capable
>of dashing off a fast tool for intensive use in other environments.

...let me know when you finish sh2c, too :-)

As for prototyping, I do that already, and p2c wouldn't do me much
good, since the Perl idioms I use for ease of implementation would
make ugly C.  The resulting code probably wouldn't run on both HPUX
and SunOS anyway.

My next project will be prototyped in Perl, and the protoype will
probably be relied on for at least six weeks in our user environment
(can 3500 users break the account administration system?).  Parts of
it will be rewritten in C as needed, to improve performance or
robustness.  Large parts of it may remain in Perl forever, to make
sure it works on all of our architectures (Pyramid 98, HP 9000 300 &
800, Sun 3 & 4, NeXT, IBM RT, BBN Butterfly, Encore Multimax, and
whatever else we get soon).  If it works out as well as I expect it
too, I won't hesitate do distribute the Perl with the C.

(side note: p2c *is* in Larry's wishlist for future additions)
-=-
J Greely (jgreely at cis.ohio-state.edu; osu-cis!jgreely)