rh@smds.UUCP (Richard Harter) (06/11/91)
Most of the articles on the ap thread have expired here; in particular I missed
the original article that sparked the exchanges. Byron, I gather, dislikes
the style of Perl and would like, so to speak, an anti-Perl, even if he has
to write it himself. This is really a lang.misc topic, so I've added that
as a group.
Byron, you don't want to do it. It's more work to develop a language than
one might imagine, particularly if it is to be a good one. If you don't
like Perl there are a number of perfectly reasonable alternatives, among
them TCL, Python, and Icon. There is also Lakota, which I am a principal
developer. [Apologies to all who fuss about people talking about their
own work duly made. My justification is that I want to talk about the
language design issues, which are of general interest to those who are
interested in language design issues.]
Briefly, Lakota occupies the same general linguistic niche as Perl, but
it is about as far as one can get from the style of Perl. When I say the
same niche, what I am getting at is this: The power of UNIX shell programming
rests not in the shell language itself, but in the collection of tool
programs that are standardly available, e.g. sed, awk, find, uniq, sort,
and their interconnection with pipes and redirection. There are a number
of problems with this bag of tools approach, however. These include
(a) the execution of the resulting scripts is slow because each tool is
a separate process, (b) most of the tools (and the shell itself) have
various size limitations, (c) the standard tools do not complement each
other completely, (d) the implementations of the tools vary from OS to
OS, and (e) there are numerous conflicts between command line usage
in the shell and the principal tools. And that's only the beginning of
the list :-).
The Perl solution (and the Lakota solution) is to provide a single language
which has the functionality of the shell and the principle tools. Now
the approach that Larry has taken with Perl is to, in effect, fuse the
major tools of UNIX into a single language with a common syntax and
the annoying limitations removed. This approach has a number of merits;
it fits in with the UNIX/C style, which offers both familiarity and
the use of a proven intellectual technology.
The approach taken in Lakota is much more radical for those who are
accustomed to doing everything "the UNIX way" although not particularly
radical in terms of languages in general. The essence of the matter is
to accept the shell tools functionality as a requirement but scrap the
entire shell syntax and style. In a sense this is a dangerous step
because one has to resolve a lot of issues anew. However there is a lot
to gain. Conventional shell programming has many faults than the ones
I have listed above. What they amount to is that shell programming
involves scripts that are hard to read, hard to maintain, and programming
structures that do not scale up well to large programs.
Some of the features that make Lakota an 'anti-Perl' are:
(A) Brutally stripped syntax. The only special characters are (){} and
the white space characters. There are no quote characters, no meta
characters and no escape character, and no need for them.
(B) English language commands. Call it COBOL if you like. The upshot
is that someone who has a modest command of the language can read it
and maintain it without being a language lawyer.
(C) A hierarchical procedure/module structure with variable isolation
between procedures and modules. Variables are, by default, local to the
procedure they used in; they can be made global to a particular modules.
All inter-module coupling must be done via explcitly shared procedures.
(D) Variable substitution is done via enclosure in parentheses and may
be nested, e.g. (a-(b)) means replace (b) by the contents of b and then
result the resulting string (concatenation of a- and contents of b) by
its contents.
(E) A minimal number of special variables; functional operators are
used instead. [Braces {} are used to delimit functions.] Thus
{all-arguments} for the list of all arguments and {argument 15} for the
15'th argument.
And so on and so forth.
The main point I would like to make is that it is not such a simple thing
to design and implement a language, particularly one which is to have
strong string manipulation capabilities.
Also this article is longer than it should be.
--
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb. This sentence short. This signature done.