NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/unix/shell/5247

Internet Message Format | 1993-01-05 | 1.7 KB

Path: sparky!uunet!psinntp!internet!sbi!zeuswtc!cyclone!bet
From: [e-mail] (Bennett Todd @ Salomon Brothers Inc., NY )
Newsgroups: comp.unix.shell
Subject: Re: ksh 1, perl 2 - ksh or perl for scripting?
Message-ID: <[e-mail]>
Date: 5 Jan 93 03:46:12 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Salomon Brothers, Inc.
Lines: 21

Actually, when it comes to clarity of code, I think Perl wins over sh or C,
precisely because there are more ways to do a thing. I try to make code
visually clear [at least to me:-]. I try to adjust the functional
organization and layout of the source code to reflect the logical
description of what it's doing; the more choices I've got in flow-of-control
constructs the better. I find the combination of Perl's named blocks, the
``next LABEL'' and ``last LABEL'', and the pattern matching against the
default match space $_, to work particularly well for many programs I write.

I'm also a big fan of top-down design and bottom-up implementation, and I
find Perl's package system of namespace management to be very comfortable
and natural for the job. I can implement reusable packages to implement the
trickier lower-level functionality, starting with a spec for the interface
to the package. Then I can debug the package with simple test drivers, or
even calling it interactively from ``perl -de 0'' in a JOVE interactive
shell window. Once the package is all set I can use its external entry
points as a new collection of primitives to write the next higher level of
functionality. I've enjoyed good code reuse with this approach.

-Bennett
[e-mail]