From: lwall@netlabs.com (Larry Wall)
Newsgroups: comp.unix.shell
Subject: Re: Shell Scripts vs. C programs
Date: 2 Sep 92 19:10:12 GMT
Organization: NetLabs, Inc.

In article <FRIEDMAN.92Sep2045423@nutrimat.gnu.ai.mit.edu> friedman@gnu.ai.mit.edu (Noah Friedman) writes:
:    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).

Don't apologize.  Perl's grammar is totally broken on purpose.  It's
just that it's slightly *less* totally broken than Unix's grammar.  :-)

Perl is nothing more or less than Pidgin Unix.

(That being said, you might be interested to know that Perl 5's yacc grammar
is (at the moment) only 60% the size of Perl 4's.)

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

Yes, the features were adopted, but they weren't *hastily* adopted.
An enormous amount of thought went into blending many things that
people are familiar with, in such a way that they still generally do
what people expect.  That was hard work!  Certainly there are some
things that I'd do different if I had them to do over, but on the whole
*I* like what I have so far.  If it makes other people happy, all the
better.

Let me say a thing about orthogonality.  It's great for instruction
sets.  It's not so good for human languages.  Many humans seem to
prefer to learn a richer language that lets them be more expressive.
They like it when there's already a word for what they're thinking.
Would you rather write assembly language in VAX or in SPARC?

: There are various annoying context-dependent misfeatures in perl as well,

Give me a list, and I'll tell you which ones I'm fixing in Perl 5,
and which ones aren't misfeatures.  :-)

: and multi-dimensional/nested arrays are cumbersome (the associate array
: features in awk are much easier to deal with).

Huh?  Perl's associative arrays are almost exactly like awk associative
arrays.  I don't see your point.  (But before you explain, I should
point out that in Perl 5 (getting tired of that yet? :-) it will be easy
to nest arrays.)

: Perl also suffers from
: being too redundant---there are tons of gratuitous looping constructs that

Which "gratuitous" looping construct would you get rid of, and why?
I can't think of one I could get rid of without making me immensely
unpopular.  The weakest component is the continue block, and that's there
so we can define the for (;;) loop rigorously.

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

That's a base canard!  Having several ways to say things does NOT
decrease readability.  It lets you say the important thing first.
Tell me, would you rather read something written by a lawyer, or
by an essayist?  It's the lawyers who must keep their "whereases" in
order.  The essayists are free to speak their minds the way they think.

That's why people enjoy writing Perl.  It "lays under the fingers",
as a musician would say.

Personally I think if/unless/while/until is an example of orthogonality
that is MISSING from your typical computer language.  Didn't it ever
bother you that Pascal had

	while CONDITON do STATEMENT
	do STATEMENT until CONDITION

Why should the positioning of the exit condition invert the value of
the test?  To C's credit it uses the same thing on both ends.  But many
people don't think "if not CONDITON then STATEMENT" though.  They think
"STATEMENT unless CONDITION", or they deMorganize the CONDITION to get
rid of the "if not", or reverse the then and the else, or use an
operator with a negative notion built in.  Inverting the logic based on
the presence or absence of a single ! is borderlinedly unreadable in my
book.  Forcing folks to say things like "if (!noglob)" is Bad Design.
In English, "if not" is usually a synonym for "otherwise".

: The idea of function calls being lvalues I find to be unaesthetic as well.

They aren't in general.  I'm not sure what you're driving at here.

: Perl has lexical scoping, compilation, a package system for 
: separating namespaces, and "modules" to its credit, however.

Lexical scoping isn't until Perl 5.  Currently Perl uses dynamic scoping.

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

Well, they do complain about its design.  But as I said, I have different
goals.  I wasn't trying to do what *they've* been taught a language designer
should do.  But then, *they* keep trying to do that, so why should I?

There are some advantages to coming out of left field.  I don't claim
to be perfect (I believe "far from it" is the technical term), but I do
know what I like, and have the gumption to do something about it.  Most
people don't realize they can change the world.  Most people don't
realize they can change ME.  Sometimes even I forget.  :-)

: [Scheme musings omitted.]
: 
:    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.

The question before the house is whether Perl's facility is intrinsically
bound to its bletchery.  Incorrect answers include both "yes" and "no".

Larry Wall
lwall@netlabs.com