promoting Perl (was Re: uutraffic report (in perl))

[Mark H. Colburn]

In article <1989Nov28.064349.1421 at eda.com> jim at eda.com (Jim Budler) writes:
>dhesi%cirrusl at oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>
>} Here's why I didn't install Perl when it first appeared on Usenet:  The
>} volume of patches.  I like software that is stable, and Perl didn't
>} seem to be.  It's too painful to keep updating a program.  It's nicer
>} to have all the bugs fixed before you install the program.  That stage
>} never seemd to arrive for Perl.

This point will never arrive with virtually any of Larry Wall's software
for the simple reason that he tends to enhance products over their
lifetime, fixing bugs, adding new features and attempting to make them run
on everything under the sun.

Software is not like cement.  You don't pour it once and then never do
anything with it again.  Software is pliable.  It has problems, or needs
new features, or should be faster, or ..., or ...

>I can't actually disagree with you, however, perl won me over with
>ONE simple example:
>	% find <path> <pattern> -exec < most any command> \;
>versus
>	% find <path> <pattern> -print | perl -ne 'equiv_command;'
>The performance improvement was HUGE!

The same improvement can be had with:

	find <path> <pattern> -print | xargs <any command>

I would venture to say that the xargs version may actually be faster than
the perl version.

I'm not trying to bash perl, but check for tools that already exist and use
them where appropriate.  Perl is a great program for doing data
manipulation and report processing and stuff, but it is not intended to be
a panacea for all lifes little problems.  It's not necessarily  the most
efficient thing out there for pasting command line arguments together and
feeding them to an arbitrary command, for example.

-- 
Mark H. Colburn                       mark at Minnetech.MN.ORG
Open Systems Architects, Inc.