Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/3/84; site talcott.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!tmb
From: tmb@talcott.UUCP (Thomas M. Breuel)
Newsgroups: net.ai,net.lang.lisp,net.lang.ada
Subject: Re: Thus spake the DoD...
Message-ID: <306@talcott.UUCP>
Date: Fri, 1-Mar-85 23:33:32 EST
Article-I.D.: talcott.306
Posted: Fri Mar  1 23:33:32 1985
Date-Received: Sun, 3-Mar-85 03:51:00 EST
References: <417@ssc-vax.UUCP> <676@topaz.ARPA> <6982@watdaisy.UUCP> <3223@utah-cs.UUCP> <7016@watdaisy.UUCP>
Organization: Harvard University
Lines: 60
Xref: watmath net.ai:2571 net.lang.lisp:350 net.lang.ada:202

> concept.  But these two features have made LISP one of the most
> inefficient languages in existence.  In many ways this inefficiency

Through techniques like CDR coding or monocopy lists, the addition of
specialised data types, the detection of tail recursion and other freedoms
that a LISP compiler has with program transformations (the properties
of LISP functions are a lot easier to specify and detect than the
properties of, say, 'C' functions), modern LISP compilers are at least
as efficent as compilers for any other language.

> Writing in LISP is challenging and fun.  It's simplicity both liberates
> and constrains the programmer so that writing LISP programs is

Where does it constrain the programmer?

> something like solving a puzzle or playing chess.  Many intelligent
> people enjoy this aspect of LISP.  Unfortunately LISP programs remain a
> puzzle even after they are written.  LISP programs are both
> syntactically and logically hard to document.  Usually only the
> original author will fully understand how a LISP program works, and
> after a few years not even he will.

Large LISP programs are developed mainly at universities, where the
coordination and guidance during software development is not as strict
as in the real world. How maintainable a large program is is largely
dependent upon the management during software development, and not
upon the particular programming language used.

> greatly exaggerated.  Not only can one now chose one of the LISP
> offspring such as PROLOG or FORTH, but also if one is writing an actual

Neither FORTH nor PROLOG are 'offspring' of LISP in any sense. They
were developed independently and share almost no features with LISP.

[I doubt very much, btw, that FORTH is a suitable programming language
for AI applications (or any applications whatsoever...). I am not
saying this out of the blue, but I have actully worked with FORTH
interpreters for many years and written several implementations for
micros. Under the constraints of an 8 bit microprocessor it is probably
the best you can do, but avoiding decent memory management and
parsing on any larger machine is dilettantism.]

About the only thing that LISP, PROLOG and SMALLTALK have in common
is an intelligent storage management system (the 'infinite memory
model'), and a very simple 'interface' to the data structures (i.e.
the 'list' abstraction, the 'functor' abstraction, and the 'object'
abstraction).

> production system one should examine one of the more efficient
> algorithmic languages to see if it is adequate for one's application.

['production system' is a bad choice of words in this context...]

I am sure that software companies that make a living off AI programs
have considered very well what programming language makes their program
development cheapest.  Most of them seem to use LISP for AI type
applications.  Don't forget that LISP is not only a programming
language, but also a programming environment.

						Thomas.