[86] in Back_Bay_LISA
Perl before swine
daemon@ATHENA.MIT.EDU (Tom Fitzgerald)
Fri Nov 20 18:45:16 1992
From: Tom Fitzgerald <fitz@wang.com>
To: bblisa@inset.com
Date: Fri, 20 Nov 92 13:18:28 EST
> Is it true,
> as I've heard, that Larry Wall admits that Perl has a lot of problems
> but says he doesn't have time to fix them and still have a life? If
> so, I think that's a good argument for not using it.
I think it's more that there are a lot of things he'd like to add, rather
than things that need to be fixed. Granted, there are some problems, but
even if it's not perfect, it still fits its ecological niche far better
than anything else.
C is nowhere near perfect either, but nobody's in any position to fix it
either.
> Maybe some of the people involved in this discussion can come up
> with some examples of problems where Perl is required, where a
> combination of "the usual" can't be used to get results.
It's never "required". Anything that can be written in perl can be written
in C, sh, Turing code or Conway's life-patterns. Perl's advantage is that
the development time is far shorter than anything else.
Perl makes a fantastic prototyping language, by the way, even for things
that later get recoded in other languages.
> I'll give
> you that dbm and sockets are going to require me to write some C
> code if I stick to the programs that come with, e.g., SunOS, but
> I don't see why I'd want to use them in what amounts to a shell script.
The category "what amounts to a shell script" is conceptually limited by
the things you're accustomed to using the shell to do. With perl, many
things that would have been serious C programs, like TCP/IP daemons,
mail-delivery controllers, DNS-tree browsers, etc., become things that
"amount to a shell script". And HUGE scripts become much simpler.
Perl sucks in the top-end of scripts and the bottom end of C programs
(especially text-intensive ones). You wouldn't want to rewrite gcc in
Perl, or "ps -aef|egrep nn", but if perl had been around years ago, things
like pathalias, newsgate, archive-servers and arbitron might have been
written in it, or at least prototyped. It would be feasable to write
sendmail in perl; this has been discussed on the net.
The architypical perl program is "rename", that lets you do things like
"rename y/A-Z/a-z/ *" to turn all the filenames in a directory to
lowercase, or "rename 's/-save$//' *-save" to strip a -save suffix off all
filenames. The program is
#!/usr/local/bin/perl
#
# From: tchrist@convex.COM (Tom Christiansen)
# Here's one version of rename, a generic utility to perform infinite
# contortions on your filenames. It's surely more powerful than anything
# of its ilk I've ever seen before.
$op = shift;
for (@ARGV) {
$was = $_;
eval $op;
die $@ if $@;
if ($was eq $_) {
print "Rename '$was' skipped, same name.\n";
} else {
rename ($was, $_) || print "Rename '$was' to '$_' failed: $!\n";
}
}
> I recently wrote a script which uses multiple concurrent background
> processes to speed up an operation across 160 Unix systems. It's
> written in Bourne shell, grep, and sed. How hard is it to do
> something like that in Perl?
It depends on other things: if the script did nothing except grep/sed the
hosts file to get 160 names, then rsh a C program 160 times, then it would
be possible, but hardly worth it. If the script did a pile of text-
intensive things on all those systems, synchronized them and made on-the-
fly decisions about what system to migrate to next, then perl would do this
very well.
> Does Perl give a fork()?
Nearly all the system calls, and most of the useful library routines, are
native to perl. Things like popen are implicit in the syntax of other
operations.
--
Tom Fitzgerald Wang Labs fitz@wang.com "I went to the universe today;
1-508-967-5278 Lowell MA, USA It was closed...."
--
Send mail for the `bblisa' mailing list to `bblisa@inset.com'.
Mail administrative requests to `bblisa-request@inset.com'.
