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: Cmail - C or perl or whatever
Message-ID: <2038@jato.Jpl.Nasa.Gov>
Date: 28 Oct 89 01:38:28 GMT
References: <1125@kl-cs.UUCP> <2473@convex.UUCP> <14810@bfmny0.UU.NET>
Reply-To: lwall@jato.Jpl.Nasa.Gov (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 66

In article <14810@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
: For my money, if the program is SIMPLE enough to do in Bourne that's
: the way you should do it.  It really just doesn't matter how wonderful
: some people think perl is, or C for that matter.  Most vendor supplied
: control scripts are in Bourne, so *your* new control scripts will fit in
: most seamlessly by following the standard.

There's definitely something to be said for this point of view.  I don't
write Configure scripts in perl.  (Yet.)

But an argument that says "If it's possible to do it the X way, then you must
do it the X way" doesn't carry much weight in my book.

And you speak of "the standard" as if it's something we shouldn't try
to change.  I don't like that.  I'm trying to change the standard.
Not to undo the toolbox approach--there's a proper place for that.
But to add another way to do the same things.  This is the essence of
perl's philosophy: take most of Unix except the "Unix philosophy" (meaning
the use of chewing gum and bailing wire) and put it into one tool (that
can still be used within the "Unix philosophy") so that better integration
and portability becomes possible.  You will never be "forced" to program
in perl, because I don't believe in The One True Way.  I think there
should be Two or Three True Ways.  I still program in C and shell.  When
appropriate.

: If the job is too complex
: for Bourne, then of course you use the simplest tool that suffices.

To use the "simple" Bourne shell, you have to master the complexities of
many tools, which vary from machine to machine.  We can't even decide
how to echo consistently.  Portable shell programming is close to
impossible, and when you manage it, the result is unreadable.  I suspect
portability and readability are the two main drivers for perl's rising
popularity.  That and the price.  :-)

: And please note that the cute device
: 
: 	#!/usr/bin/perl [-flags]
: 
: which lets some users run perl scripts directly by name as ziplessly as
: if they were standalone executables, DOES NOT WORK everywhere.  On my
: system, it would be necessary to create companion shell scripts or Korn
: shell aliases to invoke any such script.

Not entirely true.  The perl script can be its own companion shell script.
There's even a perl script to translate your perl scripts and insert the two
extra lines at the top.

: But finally -- if a reader thinks a certain application ought to be in
: one language rather than another, the way to show it is to submit a
: version in the desired language!  Not just sigh about the other fellow's
: poor choice of platform.

I thought submitting a version in the desired language is precisely what
he did.

I hope nobody is feeling threatened by all this.  Pluralism is at the
heart of perl, and the only imposition it will make on you in the coming
year is that you'll probably have to install it on your machine to keep
people happy.  If your boss tells you to, you might even have to learn it.
But anyone who knows awk, sed, sh and C already knows most of perl.

'sides, it's one more thing you can put on your resume.   :-)

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