Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site ulysses.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxt!mhuxi!mhuxa!ulysses!gsp
From: gsp@ulysses.UUCP
Newsgroups: net.cog-eng
Subject: Re: Consistency
Message-ID: <594@ulysses.UUCP>
Date: Fri, 2-Sep-83 02:15:30 EDT
Article-I.D.: ulysses.594
Posted: Fri Sep  2 02:15:30 1983
Date-Received: Sat, 3-Sep-83 04:44:56 EDT
References: <983@ittvax.UUCP>
Organization: Bell Labs, Murray Hill
Lines: 47

There are many aspects of "consistency" and I think they can be
discussed separately, and perhaps should be.

Here is a common problem of consistency for which there is
no solution, but I can tell you the tradeoffs.  It involves
consistency in language design, their syntax and primitives.

Suppose you want to design a language for application X.  You go out
and do a good job and people love it so much they ask for it to work on
application Y.  If you tuned language X to application X so that it was
wonderful for doing X, you may find it does not generalize well to
other domains.  On the other hand, you may have designed language X so
that generalization to other applications is easy.  In that case, you
may find that the language does not serve people well in application X.

A common example is the specialization of programming languages.
LISP is tuned to symbolic actions on lists, SNOBOL to string patterns
and their manipulation, and so on.  Applications based on some of these,
maybe a semantic network language based in LISP, are even more finely
tuned to a specific application.  This is not without a cost, though.
Once a language is tuned to one application, it loses applicability
to others. (This is not literally true.  LISP when extended in one
direction maintains its basic functions and hence their capabilities.
This is an advantage of extended languages over languages built
from token one.) Languages that provide everything for everyone
can be baroque and difficult to learn as well as implement.
Simple languages that provide the means for extension seem to be
the best alternative, though implementing them can be difficult
(but don't forsake great tools like m4 (especially the newer BTL version)
that offer such capabilities to many applications).  LISP is such a
language, as is C.  In such languages, libraries (extensions) are
bound to crop up.  (I wish they did more often.)

The tradeoff can be summarized:

A GOOD ARTIFICIAL LANGUAGE SPECIALIZES IN ONE DOMAIN
AT A COST OF GENERALITY TO OTHERS.

A corollary is that a good language is inconsistent with others;
almost a paradox.

These issues: tradeoffs in language design, consistency,
and artificial languages, are discussed in more detail in
my paper Natural Artificial Languages: Low Level Processes
that should appear sometime soon in the IJMMS.  Preprints
are available from me.
	Gary Perlman	BTL MH 5D-105	(201) 582-3624	ulysses!gsp