NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/unix/shell/3759

Internet Message Format | 1992-09-01 | 5.9 KB

Xref: sparky comp.unix.shell:3759 comp.unix.questions:10637
Path: sparky!uunet!usc!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!friedman
From: [e-mail] (Noah Friedman)
Newsgroups: comp.unix.shell,comp.unix.questions
Subject: Re: Shell Scripts vs. C programs
Message-ID: <[e-mail]>
Date: 2 Sep 92 08:54:23 GMT
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Followup-To: comp.unix.shell
Organization: Free Software Foundation, 675 Mass Ave. Cambridge, MA 02139
Lines: 82
In-reply-to: [e-mail]'s message of 1 Sep 92 17:36:04 GMT

In article <[e-mail]> [e-mail] (Donn Cave) writes:
>language that would have "software engineering" features for writing large
>systems.  For me, that would mean some level of typing, structured types,
>functional scoping, and some way to deal with code in separate modules,
>but I'm sure there's more to it if one were to consult some standard texts
>on this issue.  Would be nice to be able to create somewhat complex data
>types, e.g., trees, and store "pointers" to functions, but not necessarily
>the way C does it, maybe more like Lisp.

   I've been thinking about this for awhile, especially since I started
using perl.  Having a tool like perl is the right idea for typical unix
applications, filters and so forth---fork is expensive and it's not going
to get better any time soon (vfork is *still* better than a plain COW fork
implementation), and exec is even worse---but perl's grammar and design is
totally broken (sorry, Larry).  The reason why people complain about perl
having the kitchen sink is that it has no uniform design; instead there is
a grab bag of features that look hastily adopted from other programs like
sed, awk, and grep, none of which are very orthogonal.  There are various
annoying context-dependent misfeatures in perl as well, and
multi-dimensional/nested arrays are cumbersome (the associate array
features in awk are much easier to deal with).  Perl also suffers from
being too redundant---there are tons of gratuitous looping constructs that
give programmers lots of different ways to write the same thing and
decrease readability without actually increasing the functionality of the
language (using "unless" and violating the general condition->consequent
order of expression is evil, especially since this is not a fundamental
paradigm of the language).  The idea of function calls being lvalues I find
to be unaesthetic as well.  Perl has lexical scoping, compilation, a
package system for separating namespaces, and "modules" to its credit,
however.  And it's actually powerful enough to do most of the things you
could ever want in a single process, avoiding the aforementioned fork+exec
overhead.  Perl as a general purpose interpreter is no worse than any other
language interpreter, so I think most of the objections made by "unix
purists" are off base.  They should not be complaining about perl's
functionality; they should be complaining about its design.

   I would personally like to see a Scheme-oriented scripting
program---perhaps Aubrey Jaffer's scm implementation would do for starters,
though the source code is presently too messy for me to want to touch it.
MIT Scheme is probably too large and too slow to be used for running "shell
scripts", and it's not very portable anymore, at least according to one of
the MIT Scheme hackers I talked to.  It goes without saying that
portability is a vital issue for a program of the "script language" sort.

   Scheme has a lot of interesting and powerful primitives, and it is
extremely clean (everything but the low level macro facility, which is
still being ironed out in the various standards drafts).  It has most of
the essential features perl does, and what's missing could be trivially
implemented (like filter-oriented pipelines, regexps, a generic syscall
interface, and some error system to handle unix signals as well as internal
errors).  You might be able to get away with not completely implementing
continuations (I can't imagine using the full power of this in a mere
script to sort the passwd file :-)) or the full tower of numerical types.
Who uses complex numbers in shell scripts?

  The main drawback I see at this point is that a Scheme interpreter (even
with a native-code compiler that compiles the script at startup) is likely
to be slower than perl is presently.  To minimize startup cost, most of the
scheme system itself would have to either be written in C (use scheme2c?),
or generated by a program which would byte-compile scheme code and then
dump it in C-style structures and arrays, and then have that compiled into
the real scheme system.  Not my idea of the ideal way to write a scheme
system, but it'll probably run faster.  And I think this would be more
portable than using GNU Emacs' "unexec" method for dumping.

   You'd also want to write a library of commonly used subroutines to do
various kinds of field splitting, pattern substitution, and so on.
Although the way you actually do it is bletcherous, one of perl's selling
points is that you can *quickly* write routines to get the job done.
Unless you can do the same sorts of things with relative ease in a Scheme
system, it won't be good enough to replace perl.

   Scheme has latent types, rather than manifest ones (i.e. types are
associated with values, not with variables).  Whether this is a good or bad
thing is a religious issue that shouldn't be discussed in either of the
newsgroups to which this is being posted, but just to throw some fuel on
the fire, I prefer latent types for most applications.  :-)

   Incidentally, I have a public domain Scheme implementation written in
Perl.  It's missing continuations among other things, but it's still rather
interesting... Anyone have any idea who wrote it?  There wasn't any author
listed in the copy I found.