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

Text File | 1992-09-02 | 6.1 KB | 103 lines

Newsgroups: comp.unix.shell
Path: sparky!uunet!ftpbox!mothost!merlin.dev.cdx.mot.com!merlin.dev.cdx.mot.com!lezz
From: [e-mail] (Lezz Giles)
Subject: Re: Shell Scripts vs. C programs
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: fenric.dev.cdx.mot.com
Reply-To: [e-mail] (Lezz Giles)
Organization: Motorola Codex, Canton, MA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 2 Sep 1992 14:57:25 GMT
Lines: 89

In article <[e-mail]>, [e-mail] (Noah Friedman) writes:
|>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 like perl for a similar reason to why I like English - I can express
myself in many different ways and I get the freedom to choose the most
concise and readable format.  I've used another language (an Algol
derivative at the University of Edinburgh) that had both the "unless"
and the "statement if condition" (and the "statement unless condition")
constructs, so I don't regard these as particularly evil - they give
me the opportunity to increase readability a lot.

A program is as readable as the author wants it to be and it is certainly
easy to write unreadable programs in perl - but I'd contend that it is
difficult to find a language where you can write _readable_ code as
concisely - particularly in a language which is available on so many
platforms, which is one reason that it is so popular.

[description of Scheme-orientated languages paritally deleted...]
|> ..................  And I think this would be more
|>portable than using GNU Emacs' "unexec" method for dumping.

I once spent a lot of time and trouble getting a copy of undump for my
particular architecture in an attempt to speed up a large (>2,500 lines)
perl program - it turned out that the improvement in speed by using
undump was so negligable to be irrelevant.  The perl compilation phase
is *fast*.

|>   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.  :-)

Perl types do leave a lot to be desired - like Perl 5!  I have
faith in Larry Wall to come up with something good in this area, but I hope
that he isn't sticking to the old C/Algol/etc. model of types just because
it's there - I hope he's considering other approaches.

I don't want to start a religious war - the points above are purely my
own and I don't want to spend the next 200 years defending them to the death!
If a better alternative to perl comes along then I'll think seriously about
switching (though I've invested too much time in perl to make this decision
lightly), but I like its design because (1) it gives me the flexibility to
write my code as I want to, not as the language designer decided I should;
(2) I can do just about anything I want to in fewer lines of code and in a
more reliable way than in any other language.

Lezz "all hail to the Wall" Giles