Thus spake the DoD...

Thus spake the DoD...

[Frederick J Dickey]

[gourmet line eater snacks: * * * * *]

The DoD has announced its intention to make Ada the single, common,
computer language for Defense mission-critical applications. Presumably,
this means that if you have a Defense mission-critical application of AI, 
then you're going to program it in Ada. Is this reasonable? Is this
possible? Now I happen to work in an AI group of a large aerospace
company located in the general vicinity of Seattle, WA, so the answers
to these questions are of considerable interest to me. What do people
out there on the net think about this? Should AI people rush out and 
buy Ada manuals? Sell their Symbolics stock? Roll over and play dead?
Or what?

To help get this discussion off the ground, I am including three
hypothetical responses to my questions. 

-------------------------------------------------------------------------
HYPOTHETICAL RESPONSES
-------------------------------------------------------------------------

[response from Byron Kapse: I do all my AI programming in Ada. Lisp is an 
archaic dinosaur from the 50's. Ada is the language of the 80's. It's the 
first non-von Neumann language. It results from years of research into 
concepts that encourage and enforce good programming practices. Ada is the 
basis for a new culture of software engineering. The AI community can
definitely benefit from the discipline that results from the use of Ada.
The DoD is well advised to mandate the use of Ada for embedded applications, 
including embedded AI applications.]

[response from John McCadr: No way the DoD is going to use Ada for AI; they're
out of their minds. Give me one example of a significant AI system written in
Ada. It's is a von Neumann nightmare! Using Ada is like trying to brush 
your teeth with a strait jacket on. If you paid Ada programmers 5 cents a line 
to code Ada, they'd become millionaires. The DoD is going to have to admit 
that Lisp is the only way to go. Modern Lisp environments represent over 
thirty years of experience. We know how to do it. A programmer at a Lisp 
workstation like a Symbolics or LMI can blow the socks off any Ada programmer 
alive.]

[response from John Q. Programmer: Why can't we have our cake and eat it too? 
I have a product specification for a Lisp that is based upon Ada. Apparently, 
what this product does is take Lisp source code and translate it into Ada. 
So if the DoD says "do it in Ada," all you have to do is show them the 
translated code and they'll be happy while you can do your coding in Lisp. 
Besides that, this product allows you to combine the symbolic processing 
capability of Lisp with the number crunching capability of Ada. You get 
the best of both worlds! This really looks like the way to go.]

Re: Thus spake the DoD...

[Robert Hofkin]

I say: don't believe everything the government tells you.  There are
exceptions to the STARS initiative you could drive the entire DoD
through!  First, eliminate projects that aren't "mission critical."
Second, forget all but "embedded systems." Third, find an Ada compiler
that will work (i.e., generate small, quick code) in the remaining
environments (things like missles).  Unless you have ALL THREE, Ada
won't be REQUIRED.  Where it isn't required, Ada probably won't be used
because of the high retraining cost and investment in existing
language-specific software development tools.

Re: Thus spake the DoD...

[g-frank]

> I have a product specification for a Lisp that is based upon Ada. Apparently, 
> what this product does is take Lisp source code and translate it into Ada. 
> So if the DoD says "do it in Ada," all you have to do is show them the 
> translated code and they'll be happy while you can do your coding in Lisp. 

Real unlikely, guy.  The whole point of Ada was that the DoD was tired of
supporting the creation and maintenance of code in several hundred different
languages.  If your package was WRITTEN in Lisp, and is MAINTAINED in Lisp,
I don't think DoD will care if you can mechanically translate it into Swahili.
It won't be acceptable.


-- 
      Dan Frank

	  Q: What's the difference between an Apple MacIntosh
	     and an Etch-A-Sketch?

	  A: You don't have to shake the Mac to clear the screen.

Re: Thus spake the DoD...

[Skef Wholey]

The major figures in the Common Lisp world are currently working closely
with ARPA to establish a sort of "standards organization" for Common Lisp.
Folks at ARPA are very interested in having Common Lisp become the required
language for DoD AI work.  The biggest obstacle to Common Lisp becoming
such a standard at this point is Xerox and Interlisp community, not the Ada
folks.
-- 
uucp: ...!seismo!cmu-cs-spice!skef
arpa: skef@CMU-CS-Spice

Re: Thus spake the DoD...

[Chuck Hedrick]

There is an escape clause in the Ada promulgation.  That allows other
languages to be used for special applications where there is good reason to
do so.  At the Common Lisp conference it was said that the ARPA Strategic
Computing project would have Common Lisp as a major language.  I think there
is going to be a de facto standard exception for AI programs that let them
be done in Lisp.

Re: Thus spake the DoD...

[Daniel J. Salomon]

> There is an escape clause in the Ada promulgation.  That allows other
> languages to be used for special applications where there is good reason to
> do so.  At the Common Lisp conference it was said that the ARPA Strategic
> Computing project would have Common Lisp as a major language.  I think there
> is going to be a de facto standard exception for AI programs that let them
> be done in Lisp.

I think that far too much emphasis has been placed on the need for LISP
in AI work.  The things that were novel when LISP was introduced are
not so rare anymore.  Most AI programs written in LISP could be written
equally well or better in other languages.

The real problem is that there is a large body of AI software written
in LISP that will not be easily converted to or rewritten in Ada.  The
effort would be just too massive.  To justify such an endeavor, the
benefits of converting them to Ada would have to be enormous.
Similarly there is a large group of AI programmers who are experts in
LISP who would have to spend (or waste) a great deal of time becoming
equally proficient in Ada and building up the same tools and techniques.

However similar problems exist in other disciplines.  Numerical analysis has
traditionally been done in Fortran, and Fortran is considerably more
similar to Ada than is LISP.  But it will still take a massive amount
of effort to convert all the tried and trusted FORTRAN numerical-
analysis subroutines into Ada.  Any DOD directive requiring the use of
Ada will have to have loopholes because instant conversion is
impossible and foolish.

LISP &c (re: the DoD...)

[Thomas M. Breuel]

> I think that far too much emphasis has been placed on the need for LISP
> in AI work.  The things that were novel when LISP was introduced are
> not so rare anymore.  Most AI programs written in LISP could be written
> equally well or better in other languages.

I disagree. LISP combines the following features:

-- smart memory management
-- a universal data structure (note the singular...)
-- simple but general syntax
-- procedures as manipulable objects

If a 'substitute' for LISP has the same characteristics, you may as
well go ahead and call it 'LISP'.

This is not to say that there are no special purpose languages which
are better adapted to one or the other category of AI problems.  This
is also not to say that with the advent of different computer
architectures other programming languages may take the place of LISP
(e.g. PROLOG).  For a conventional architecture, however, LISP is
probably the most general and most useful AI programming environment
you can build.

						Thomas.

Re: Thus spake the DoD...

[Jan Steinman]

I think many of you are either missing the boat completely, or have not
actually read the DOD directives.  Although I don't have them in front of me,
(and am, therefore, guilty of what I am accusing others) I can recall quite
clearly that the original directive refered to *embedded systems* entering
*advanced development* by a certain date.  Once DOD gained confidence in Ada,
a more general directive refering to all *mission critical systems* which
were *entering advanced development* by a certain date was issued.

Everyone seems to be on to the *embedded systems* part, but examine the
implications of the other two phrases:

1) "entering advanced development by..."  No one is suggesting that huge,
	presumably working FORTRAN or Lisp programs will be re-written in Ada!
	If a new system entering advanced development depends on previously
	written code in some other language, Ada is flexible enough that an
	interface can be written so the previous code can appear as an Ada
	package.  Of course, unscrupulous DOD contractors may use this as an
	excuse to soak the DOD for a needless re-write, but that's another
	issue...

2) "all mission critical systems..."  There is certain latitude in the
	interpretation of this phrase, but it is much larger in scope than
	"embedded systems".  Until Ada expertise is widespread, I suspect this
	means that if two organizations bid a job, one using Lisp, the other
	Ada, the Ada bidder will get the job.  Note that everything is a
	"mission" in military jargon -- if a soldier's duty is to compile a
	program, the compiler is "mission critical".

The services differ greatly in embracing Ada.  Those who want or need to work
in the military-industrial complex and are unwilling or unable to learn an
exciting new language should probably start looking for Navy contracts and
avoid Air Force work at all costs.  (The Army falls in between, but is much
closer to the AF's enthusiasm for Ada than the Navy's grudging acceptance.)
-- 
:::::: Jan Steinman		Box 1000, MS 61-161	(w)503/685-2843 ::::::
:::::: tektronix!tekecs!jans	Wilsonville, OR 97070	(h)503/657-7703 ::::::

Re: Thus spake the DoD...

[Stanley Shebs]

>
>I think that far too much emphasis has been placed on the need for LISP
>in AI work.  The things that were novel when LISP was introduced are
>not so rare anymore.  Most AI programs written in LISP could be written
>equally well or better in other languages.

The way we say it around here is "most programs written in *other* languages
could be written better in Lisp" - that includes work in VLSI, graphics,
compilers, algebra, and suchlike.  Name me ONE thing that Pascal or Ada
does better than Lisp (besides `confuse and frustrate the programmer')...

							stan shebs

Re: Thus spake the DoD...

[Daniel J. Salomon]

> The way we say it around here is "most programs written in *other* languages
> could be written better in Lisp" - that includes work in VLSI, graphics,
> compilers, algebra, and suchlike.  Name me ONE thing that Pascal or Ada
> does better than Lisp (besides `confuse and frustrate the programmer')...
> 
> 							stan shebs

Since LISP is a typeless language a LISP interpreter or compiler will
accept almost any meaningless input (in which the parentheses match)
as a valid program.  Thus the correctness of programs must be proved by
exhaustive test cases or by theoretical analysis.  Although LISP is
more amenable to theoretical analysis than most languages, let's face
it, most LISP programmers would rather hack out another test case than
do any analysis.

Since LISP uses function notation for all operations it is a simple
language to implement and a simple language in which to automatically
generate code (thus the AI connection).  Similarly its use of lists to
implement all data types and all structures is a simple and interesting
concept.  But these two features have made LISP one of the most
inefficient languages in existence.  In many ways this inefficiency
has hindered the development of AI.  People now associate AI with
programs that are too costly to run.

This inefficiency has led LISP programmers on an endless search for
more powerful hardware.  The search may lead to new and exciting
parallel architectures but until they are designed and built we should
find ways to make good use of the hardware we have.

Writing in LISP is challenging and fun.  It's simplicity both liberates
and constrains the programmer so that writing LISP programs is
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.

I thus stand by my original claim that the importance of LISP to AI is
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
production system one should examine one of the more efficient
algorithmic languages to see if it is adequate for one's application.

Re: Thus spake the DoD...

[Stanley Shebs]

There's so much misinformation in djsalomon@watdaisy that I'd better
respond in some detail, lest a bystander get a mistaken impression:


>Since LISP is a typeless language a LISP interpreter or compiler will
>accept almost any meaningless input (in which the parentheses match)
>as a valid program.  Thus the correctness of programs must be proved by
>exhaustive test cases or by theoretical analysis.  Although LISP is
>more amenable to theoretical analysis than most languages, let's face
>it, most LISP programmers would rather hack out another test case than
>do any analysis.

Typechecking is a very small and relatively trivial part of program
correctness.  In any case, Lisp is *not* a typeless language - it
is polymorphic, which is much different.

>Since LISP uses function notation for all operations it is a simple
>language to implement and a simple language in which to automatically
>generate code (thus the AI connection).  Similarly its use of lists to
>implement all data types and all structures is a simple and interesting
>concept.  But these two features have made LISP one of the most
>inefficient languages in existence.  In many ways this inefficiency
>has hindered the development of AI.  People now associate AI with
>programs that are too costly to run.

Every modern Lisp includes a vector datatype, which is like a
one-dimension array in low-level languages.  The most sophisticated
Lisps (such as Common Lisp) include a wealth of other datatypes
intended for high efficiency in applications.  For many years,
the Maclisp compiler on the DEC-20 has produced numerical code
superior to Fortran.

>This inefficiency has led LISP programmers on an endless search for
>more powerful hardware.  The search may lead to new and exciting
>parallel architectures but until they are designed and built we should
>find ways to make good use of the hardware we have.

PSL is one of the fastest Lisps around, and it runs on Vaxen and 68000s,
among other general-purpose machines.  Not everyone agrees with
the "Lisp Machine" approach!

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

And Pascal programs are supposed to be marvels of clarity?  I've
read many Lisp programs by other people, and it's evident that
the formatting, organization, and documentation of a program is
more important than the language it is written in.  In favor of Lisp
is that programs tend to be smaller and less contorted, thus easier
to deal with.  There are other advantages, but space doesn't permit...

>I thus stand by my original claim that the importance of LISP to AI is
>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
>production system one should examine one of the more efficient
>algorithmic languages to see if it is adequate for one's application.

Prolog is a descendent of Lisp only by the most contorted of genealogies
(via Planner and Conniver).  Forth was developed completely independently
by a radio astronomer (if I recall correctly).  There are many "actual
production systems" written in Lisp - will give examples if anybody
asks...

							stan shebs

Re: Thus spake the DoD...

[neves]

To: uwvax!harvard!godot!mit-eddie!genrad!decvax!bellcore!allegra!ulysses!mhuxr!mhuxj!houxm!ihnp4!cbosgd!clyde!watmath!watdaisy!djsalomon
Subject: Re: Thus spake the DoD...
In-reply-to: your article <7016@watdaisy.UUCP>

Since LISP uses function notation for all operations it is a simple
language to implement and a simple language in which to automatically
generate code (thus the AI connection).  
--> Most AI people do not do automatic programming.  They use Lisp because
    it is a great language for trying out new ideas.  Does your favorite
    language have incremental function compilation?  Try a Lisp machine.

Similarly its use of lists to
implement all data types and all structures is a simple and interesting
concept.  

-->  This is simply not true.  Lisps have arrays and strings and the
     more modern ones have records and objects.

But these two features have made LISP one of the most
inefficient languages in existence.  

--> Nothing true about this statement.  What is so inefficient about CONS?
  Why don't you be specific in naming some part of Lisp that is inefficient?
  Below is the Pascal equiv. of CONS.  People think Lisp is efficient because
  they see it work on very large and difficult problems.
  function cons(a,b:cellptr):cellptr;
  var newcell:cellptr;
  begin
  new(newcell);
  newcell^.left:=a;
  newcell^.right:=b;
  cons:=newell
  end;

In many ways this inefficiency
has hindered the development of AI.  People now associate AI with
programs that are too costly to run.
This inefficiency has led LISP programmers on an endless search for
more powerful hardware.  The search may lead to new and exciting
parallel architectures but until they are designed and built we should
find ways to make good use of the hardware we have.

--> The reason that AI is moving to parallel architectures is that
the problems they face demand such an architecture.  The Japanese
are doing the same thing for business (data base) problems in the
fifth generation systems.

Writing in LISP is challenging and fun.  It's simplicity both liberates
and constrains the programmer so that writing LISP programs is
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.

--> Lisp programs (or parts of them) have been published many times.
   They are not so difficult to understand.  One of the problems with
   early Lisps was that there wasn't any reasonable iterative
   construct and used PROG (which complic;ated code if used
   incorrectly).  The current Lisps have DO.  You should not be
   judging Lisp based on the Lisp 1.5 version of the early 60's.

I thus stand by my original claim that the importance of LISP to AI is
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
production system one should examine one of the more efficient
algorithmic languages to see if it is adequate for one's application.

--> Once your ideas are set then it might be feasible to implement them
  in a different language, even assembly language.  But most (if not all)
  AI people would feel they were wasting their valuable time if subjected
  to a Forth, C, Pascal, ADA, etc.
-- 

...!{allegra,heurikon,ihnp4,seismo,uwm-evax}!uwvax!neves
neves@uwvax

Re: Thus spake the DoD...

[Thomas M. Breuel]

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

Efficiency of LISP

[Marty Sasaki]

There was an informal experiment done in the early-mid seventies at MIT
that compared MACLISP with other programming languages. Basically a
translator was written to translate (say) FORTRAN into MACLISP. Both
versions were compiled, and the programs were run and the results
compared. The translators were simple and did no real optimizing of the
code, everything was up to the lisp compiler.

In every case the lisp versions ran faster and took up less memory. The
experiment was done on either a KA-10 or a KL-10. I remember being
amazed at the FORTRAN results. The programs being used were purely
computational ones, things like matrix handling and iterative modeling
simulations.

I don't remember much more. Could any of the principles shed further light?
-- 
			Marty Sasaki
			Havard University Science Center
			sasaki@harvard.{arpa,uucp}
			617-495-1270

Language criticism

[Greg Davidson]

<flame on>

I am getting very tired of opinionated articles from people who don't
have expertise and experience backing them up.  I have just read a
string of articles telling us all why we shouldn't use LISP from people
who have only a faint acquaintance with the language.  A similar
situation is going on in net.lang.c about Modula vs. C.  In both cases,
the people who are devout adherents of language X think that they have
the goods on language Y.  I have noticed that expert responses are less
and less frequent and assume that the experts are fed up and are
unsubscribing from these newsgroups.  This is impoverishing us all.

The opinions I had about LISP before I had had major experience with
the language are laughable.  With my exposure to only mainstream languages
(FORTRAN, ALGOL, Pascal, etc.) I was unable to understand why anyone
should use LISP.  After going through a complete turnaround with LISP
(and a milder version of the same thing with PROLOG), I will now spare
the community the burden of my uninformed opinions.  I ask the same of
the rest of you.

I have read almost no informed criticism of LISP in any of these
groups, so if you're thinking ``at least MY opinions are justified'',
then you are almost certainly one of the offenders.  I will follow up
this article with a later one revealing some of the common
misconceptions about LISP, but for now I don't want to dilute my
point.  Before I unsubscribe from the newsgroups that claim to be
forums for some of my favorite topics, I intend to kick up a fuss.

<flame off>

_Greg

Re: Thus spake the DoD...

[geb]

>I thus stand by my original claim that the importance of LISP to AI is
>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
>production system one should examine one of the more efficient
>algorithmic languages to see if it is adequate for one's application.

Has FORTH changed since I last looked at it?  Then, it didn't
support dynamic variables (like lists of arbitrary length).
I suppose you could write some routines to do that, but then
wouldn't it be like lisp, and need something like gc?  Without
dynamic variables, how could you do ai?

Re: Thus spake the DoD...

[David Schachter]

Mr. Shebs asks for one thing that Pascal or Ada do better than Lisp.  One
thing is that Pascal runs on the IBM  PC and other low-end, cheap, widely
available hardware platforms.  If you want other people to buy your programs,
this is can be an important thing.  Lisp has a reputation for not running well
on small cheap boxes.  If this reputation is deserved, then Pascal is a better
choice for some applications.  (Elegance isn't everything.  Profitability
counts too.)

I don't read this group frequently so you might want to send replies to me
via mail.
                       -- David Schachter

Re: Thus spake the DoD...

[Stanley Shebs]

In article <76@daisy.UUCP> david@daisy.UUCP (David Schachter) writes:
>
>Mr. Shebs asks for one thing that Pascal or Ada do better than Lisp.  One
>thing is that Pascal runs on the IBM  PC and other low-end, cheap, widely
>available hardware platforms.  If you want other people to buy your programs,
>this is can be an important thing.  Lisp has a reputation for not running well
>on small cheap boxes.  If this reputation is deserved, then Pascal is a better
>choice for some applications.  (Elegance isn't everything.  Profitability
>counts too.)

Our Lisp dialect PSL runs on 128K Macintoshes and is used by freshmen here.
However, it *does* use the entire available space and leaves only a very
small heap!  Harold Carr recently showed how to make compiled Lisp programs
work outside of a large environment - it hasn't been done in the past
because nobody was interested in exchanging a comfortable and sophisticated
environment for the crude and primitive ones usually associated with
C and Pascal (Un*x notwithstanding).

							stan shebs

Re: Thus spake the DoD...

[Joaquim Martillo]

If Common Lisp does not run so well on the PC, given the trend in memory
and speed and cost  for  small  personal  computers,  this  is  a  minor
consideration.   Common Lisp runs excellently on the AT and I believe is
supposed to run on the XT.  It won't be too long before the  AT  is  the
bottom of the line.

Yehoyaqim Martillo

Re: Thus spake the DoD...

[T J Jardine]

> Mr. Shebs asks for one thing that Pascal or Ada do better than Lisp.  One
> thing is that Pascal runs on the IBM PC and other low-end, cheap, widely
> available hardware platforms.  If you want other people to buy your programs,
> this can be an important thing.  Lisp has a reputation for not running well
> on small cheap boxes.  If this reputation is deserved, then Pascal is a better
> choice for some applications.  (Elegance isn't everything.  Profitability
> counts too.)
> 
> I don't read this group frequently so you might want to send replies to me
> via mail.
>                        -- David Schachter

I've sent David a personal copy of this reply, but since he chose to send to
the net, I thought it only fair that my reply should be available to the same
audience.  I think that Pascal is a fine tool for certain things, and Lord
knows I certainly hope that the DoD finds some fine applications for Ada one
of these centuries, since I'd like to see some kind of return for all the
red ink we spill.  But seriously, folks, I have yet to see a profitable Ada
program, and so has the DoD.  I'd also like to see anything but a toy system
written in an implementation of Pascal according to the original report that
defines same.  Every Pascal implementation, from UCSD Pascal on a 6502 to
Pascal on IBM or even Pascal on Unix, has had to deal with implementation
choices and "features" that the authors of Pascal either chose to avoid or
did not forsee.  I don't cast aspersions to Wirth and company; there are a
lot more issues involved than one can fit into a compact language.  What one
needs to look at is the style of problem solving.  Fortran constrains; PL/I
constrains a little bit less; Ada constrains in different ways and with
unforeseen baggage; Lisp really requires that one change his/her point of
view in problem solving, and once you have done that you have whole new
worlds opened up.  We may build on Lisp; we may even suffer under various
dialects of Lisp for some time to come; but we will not find a better
fundamental approach to problem solving than Lisp embodies for many lifetimes
to come.  Sorry for the length, but I got stuck on my soap box again!

Ted Jardine
-- 
TJ (with Amazing Grace) The Piper
Boeing Artificial Intelligence Center
...uw-beaver!ssc-vax!bcsaic!ted

Re: Thus spake the DoD...

[Jan Steinman]

In article <473@ssc-vax.UUCP> tjj@ssc-vax.UUCP (T J Jardine) writes, quotes:
>> Mr. Shebs asks for one thing that Pascal or Ada do better...  (Elegance
>> isn't everything.  Profitability counts too.)
>>                        -- David Schachter
>>
> But seriously, folks, I have yet to see a profitable Ada program, and so has
> the DoD...
>
I really wish people wouldn't do this!  All right, TJ, do you work on DOD
projects?  Do you use Ada?  Do you have much (any) exposure to those who do?
There is so much emotional outpouring when it comes to pet languages, so much
of this empty "talking through one's hat".

FACT: A company in Rockwood, MD (Intellimac) delivered one of the earliest
Ada applications in late 1982.  I don't recall the particulars (and I really
hate to waste my employer's time looking up facts for people who are to lazy
to keep up with the news) but I believe it was nigh 100,000 lines of code.
This early, if not first, application (which was widely discussed in the
trade rags) was not for rockets, bombs, or submarines.  This Ada program runs
CAM, accounting, personnel, virtually everything for a German bus
manufacturer's automated factory in North Carolina!  It performs many tasks
normally asked of Lisp and COBOL.

SECOND FACT: The DOD does not see any *profitable* programs, including those
written in Lisp.  They are a profit *sink*, not *source*.  As to whether they
find Ada a useful means to their various ends, years of defense industry work
prior to coming to Tek qualifies me to say "Yes".  Most of Ada's DOD use is
classified and doesn't show up in the National Enquirer, although it's
presence is well documented in the major DOD trade rags.

> Sorry for the length, but I got stuck on my soap box again!
>
Before you get up on your soapbox and do some more uninformed spouting off,
call Ralph Crafts (VP Marketing, Intellimac) 301/984-8000.

I don't have anything in general against Lisp, Pascal, or any other language.
I do take dim view of those who have a chip on their shoulder over make up
fairy tales to support their stand!
-- 
:::::: Jan Steinman		Box 1000, MS 61-161	(w)503/685-2843 ::::::
:::::: tektronix!tekecs!jans	Wilsonville, OR 97070	(h)503/657-7703 ::::::

Re: Thus spake the DoD...

[Robert A. Pease]

.

>                   But seriously, folks, I have yet to see a profitable Ada
>program, and so has the DoD.  I'd also like to see anything but a toy system
>written in an implementation of Pascal according to the original report that
>defines same.  Every Pascal implementation, from UCSD Pascal on a 6502 to
>Pascal on IBM or even Pascal on Unix, has had to deal with implementation
>choices and "features" that the authors of Pascal either chose to avoid or
>did not forsee.  [Ted Jardine]

Okay, I wouldn't be supprised if the DoD doesn't have a "profitable Ada
program", it takes so long to come up to speed on the language.  But, you
are asking that Pascal do something it wasn't designed to do; i.e. - work
in the real world.  The language *was* designed as a teaching tool and
people in the real world took a look at it and said, "Hey, this is great!"
Now, the extensions added to Pascal are designed to take it from the
teaching environment and put it in the real world.  No wonder they aren't
standard.

>                                                                    What one
>needs to look at is the style of problem solving.  Fortran constrains; PL/I
>constrains a little bit less; Ada constrains in different ways and with
>unforeseen baggage; Lisp really requires that one change his/her point of
>view in problem solving, and once you have done that you have whole new
>worlds opened up.  We may build on Lisp; we may even suffer under various
>dialects of Lisp for some time to come; but we will not find a better
>fundamental approach to problem solving than Lisp embodies for many lifetimes
>to come.  [Ted Jardine]

Okay, this is the first time anyone has said anything that has sparked my
interest in looking at Lisp.  So tell me, where can I find a good book to
teach me Lisp and what is it called?
-- 

					Robert A. Pease
    {hplabs|zehntel|fortune|ios|tolerant|allegra|tymix}!oliveb!oliven!rap

Re: Thus spake the DoD...

[Ed Colbert]

>...  I think that Pascal is a fine tool for certain things, and Lord
>knows I certainly hope that the DoD finds some fine applications for Ada one
>of these centuries, since I'd like to see some kind of return for all the
>red ink we spill.  But seriously, folks, I have yet to see a profitable Ada
>program, and so has the DoD.
>
>Ted Jardine

You will be pleased to know that in 1981 a company called INTELEMAC wrote 2
buisness applications in Ada which it successfully marketed.  Also the
flight software for Northrup's F-20 is written in Ada & is successfully
completed its flight tests.

In fact,  Ada is a very nice language to use for MANY applications and the
people/companies that have used it, report tremendous productivity
improvements (the gains come during unit testing & integration & test
phases, there hasn't been enough time yet to determine the gains during the
maintainace phase).

The major cost of Ada is training.  There are 2 reasons for this:

	1) It unquestionably takes more time to for someone to learn
	   Ada to the degree where they can FULLY utilizies its
	   capabilities and FULLY understand the language.  However,
	   this is at least partially do to the fact that there is so
	   much capability in Ada.
	   [NOTE: this is base both on my personal experience in
	   learning Ada & in teaching it.]

	2) Most programmers don't know Ada.

The second problem will decrease over time as more & more people learn Ada.
Also some of the cost of this instruction will be recoverd since people will
not have to be learn a new language every time they switch to a new
machine or project once they have learn Ada.


Ed Colbert

Re: Re: Thus spake the DoD...

[Monique M Taylor]

> >
> >I think that far too much emphasis has been placed on the need for LISP
> >in AI work.  The things that were novel when LISP was introduced are
> >not so rare anymore.  Most AI programs written in LISP could be written
> >equally well or better in other languages.
> 
> The way we say it around here is "most programs written in *other* languages
> could be written better in Lisp" - that includes work in VLSI, graphics,
> compilers, algebra, and suchlike.  Name me ONE thing that Pascal or Ada
> does better than Lisp (besides `confuse and frustrate the programmer')...
> 
> 							stan shebs

*** REPcccccccccbgcjywefjmwdymjwymuy      ACE THIS LINE WITH YOUR MESSAGE ***

Re: Re: Thus spake the DoD...

[Jan Steinman]

>>>I think that far too much emphasis has been placed on the need for LISP
>>>in AI work.  The things that were novel when LISP was introduced are
>>>not so rare anymore.  Most AI programs written in LISP could be written
>>>equally well or better in other languages.
>>
>>The way we say it around here is "most programs written in *other* languages
>>could be written better in Lisp" - that includes work in VLSI, graphics,
>>compilers, algebra, and suchlike.  Name me ONE thing that Pascal or Ada
>>does better than Lisp (besides `confuse and frustrate the programmer')...
>
>*** REPcccccccccbgcjywefjmwdymjwymuy      ACE THIS LINE WITH YOUR MESSAGE ***

I really have to agree that either Pascal or Ada will indeed do this better
than Lisp, however, I believe the "*** REPcccccccccbgcjywefjmwdymjwymuy"
portion is best served by FORTRAN 66, while the "ACE THIS LINE WITH YOUR
MESSAGE ***" clause is best handled by FORTH, after the requisite conversion
to RPN.
-- 
:::::: Jan Steinman		Box 1000, MS 61-161	(w)503/685-2843 ::::::
:::::: tektronix!tekecs!jans	Wilsonville, OR 97070	(h)503/657-7703 ::::::

Re: Re: Re: Thus spake the DoD...

[faustus]

> >>The way we say it around here is "most programs written in *other* languages
> >>could be written better in Lisp" - that includes work in VLSI, graphics,
> >>compilers, algebra, and suchlike.  Name me ONE thing that Pascal or Ada
> >>does better than Lisp (besides `confuse and frustrate the programmer')...

First, Pascal or Ada aren't REAL programming languages, so this isn't
a fair question. Second, how about something like printf? It's no fun
to have to do this in lisp (or worse, prolog)...

	Wayne

Re: Efficiency of LISP

[Stavros Macrakis]

> > > an informal experiment ... at MIT ... compared MACLISP with other
> > > programming languages [by] translat[ing] FORTRAN into MACLISP. ...
> > > the lisp versions ran faster and took up less memory.
> [If] both compilers were doing their best at optimizing the generated
> code, it's clear that [that] MACLISP compiler was better than [that]
> FORTRAN compiler....  This [doesn't mean] LISP is better than FORTRAN
> for numerical work, [just] that LISP may not be as bad as some
> might think.  -- 	Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy

I didn't make this measurement, but I was there.  The reason the DEC
Fortran code was worse than the Maclisp code was simply that the DEC
standard calling conventions (which Maclisp didn't use) were expensive.
Otherwise, the code was very similar.  Neither compiler produced
impressive code.  There is, of course, no inherent reason that the
inline code produced for numerical calculations in Lisp (assuming
machine arithmetic, not bignums) should be much worse than that produced
for Fortran, C, Pascal, or Basic.  Some technical reasons that a good
Maclisp compiler has to do a bit worse than a good Fortran compiler are
in the Appendix (below).

The BIG concession you make to get the efficiency, of course, is
programming with fixed-type operators (and/or declared variables and, to
my taste, stepping out of the elegant beauty of the core of Lisp (not
that the semantics of Lisp numbers was ever terribly clean).  Note, by
the way, that the MacLisp system's consistency checking is rather
patchwork:  declarations are not processed at all interpretively, and
separately compiled modules are not checked for consistent declarations.
In other words, like many Lisp extensions, numeric processing is
pragmatically useful, but semantically a mess.

The other issue is whether we are talking about `Lisp' at all.  You
could equally well add such features to Snobol and claim Snobol did
efficient numerical processing.  The problem in saying that `Lisp' does
something is that if it doesn't, someone will add it and still call it
`Lisp'!  You might as well call Ada, `Algol'.  I'm all for improvement
over time, but it is unfair to pretend that Common Lisp '85 = MacLisp
'77 = Lisp 1.5.
	-s

Appendix: Some Technical Details

The two restrictions on numerical efficiency in the PDP-10 Maclisp
implementation are 1) that only 5 registers are available for numbers,
because the rest are stack pointers or garbage-collectable and 2) that
arrays can only be referenced indirectly, because they may be relocated
between any two instructions (Maclisp allows interrupts at arbitrary
points).  Consider a loop to take an inner product of two arrays, A and
B, declared as fixed length.  A good Fortran compiler would produce
machine code like the following:
  float a[len], b[len];
  register float *cura = &(a[0]), *curb = &(b[0]);
  register float sum = 0.0; register int count = len;
  while (--count) sum = *(cura++) + *(curb++);
while Maclisp is obligated to produce (at best) something like:
  float *(a,len), *(b,len);
  register int index = 0; register float sum = 0.0;
  while (index < len) sum = *(a,index) + *(a,index);
where *(a,index) has the effect of *(a[index]) but is indivisible--a is
an indirect word.

In DEC Fortran's case, its main efficiency problem seems to be that it
stashes all registers (even ones it doesn't use) over subroutine calls.
A better compiler could fix this without doing any damage to the
definition of Fortran.  I speculate that he callee-saves discipline was
chosen so that small machine-language library routines (sqrt etc.) could
be hand-tuned to save only the registers they care about while not
requiring that a table be kept of which routines clobber what registers.

Re: Efficiency of numerical Lisp code (details)

[Stavros Macrakis]

Out of an excess of curiosity, I went back and checked DEC Fortran vs.
Maclisp code quality on the inner product problem: DEC Fortran turns out
to produce excellent code, and Maclisp gets nowhere near the performance
it could get under its runtime model.  DEC Fortran has 7 memory
reference loop; Maclisp (with full declarations), a 23 mem ref loop.  Of
course, this proves nothing about Lisp per se, just the Maclisp compiler
of 3/85.

Re: Efficiency of numerical Lisp code (details)

[Chuck Hedrick]

> Out of an excess of curiosity, I went back and checked DEC Fortran vs.
> Maclisp code quality 

I conjecture that the original test may have been against the old DEC
Fortran compiler, known as F40.  If so, your new test was against a
different Fortran compiler.  Hence different results would not be
surprising.  Does anybody who was involved in the tests know what Fortran
compiler was involved?  This particular piece of folklore (that Maclisp
generates as good code as Fortran) is more widely quoted than you might
think.  If it isn't true, or if the Fortran compiler is one that would now
be viewed as substandard, I would very much like to know.

Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[Stavros Macrakis]

> [perhaps] the original test [was] against the old DEC Fortran
> compiler, F40. .... This particular piece of folklore (that Maclisp
> generates as good code as Fortran) is more widely quoted than you
> might think.  If it isn't true, or if the Fortran compiler is one that
> would now be viewed as substandard, I would very much like to know.

It's not true.  What is true is that in some cases (heavy use of
procedures, light use of arrays), Maclisp can hold its own.  The Fortran
compiler being used was not great, but then the Maclisp compiler is
old-fashioned as far as compiler technology goes, too.

Now for the details: you asked for them....  Inner loop times only.  All
execute the same floating-point instructions, so the number of memory
references plus the number of multiplications (for 2D indexing) is a
good measure of time.

	  Version	Date	Inner prod   Sum up 2d array

F10/Opt	  V.1A	        76	   6	      6
F10	    "		76	   7	      9 + Mul
F40	  F40I V27(360) 76	   8	     10 + Mul
Maclisp	  1135	        83	  23	     16 + Mul

Note that the problems are chosen to emphasize Fortran's strength with
arrays.  In straight-line numerical code, Maclisp will do relatively
better, but still not as well as the Fortrans.  Maclisp has faster
procedure call/return as well: the DEC Fortrans take about 
	11 + 7 * arg + 3 * out-arg
mem refs, while Maclisp can take as little as
	 4 + 1 * arg ,		(if args stay in registers)
although more common is
	 6 + 3 * arg .		(if args are stashed on stack)
It is this advantage in procedure calling that was largely responsible,
if I remember correctly, for the good Lisp results in the Sigsam article
(sorry, I don't have the reference: something like 1977).  Of course,
the Fortran arguments are by-reference, and the Lisp by-value; and the
register conventions differ.  There are other, hidden, overheads in the
Lisp use of arrays, namely that in Maclisp (at least), they can neither
be stack-allocated nor statically-allocated, but rather come out of a
heap, increasing allocate/deallocate overhead.

As always, remember that all languages have their strengths and
weaknesses, that a language may have good implementations and bad, and
that speed is only one consideration.

	-s


Appendix

For your delectation, the Lisp and Fortran code, and F10/opt's output.
Note that the Fortran source is much clearer in this case, too.

Sum up 2d array

	(do ((i 0 (1+ i))) ((>= i 1000))
	    (do ((j 0 (1+ j))) ((>= j 1000))
		(setq sum (+$ sum (a j i)))))

	DO 10 I=1,1000
	  DO 10 J=1,1000
10	    SUM=SUM+A(J,I)

8M:	MOVEI	14,0(15)
	ADD	14,.O0000	; should have put .O0000 in register
	FADR	2,A-13(14)
	AOBJN	15,8M

Inner product

	(do ((i 0 (1+ i))) ((>= i 1000))
	    (setq sum (+$ sum (*$ (b i) (c i)))))

	DO 20 I=1,1000
20	   SUM=SUM+B(I)*C(I)
	END

10M:	MOVE	14,B-1(15)
	FMPR	14,C-1(15)
	FADR	2,14
	AOBJN	15,10M

Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[Tim Maroney]

That seems like some pretty dumb code to put in Lisp.  Iteration, setq --
yech!  I don't think any person in their right mind would disagree that
Fortran-like or Algol-like languages are far better suited to this style of
programming than Lisp.

Now, let's see you write a recursive linked-list program in Fortran, which
doesn't have stack-based calling, pointers, or anything remotely like
structured data types....
-=-
Tim Maroney, Carnegie-Mellon University, Networking
ARPA:	Tim.Maroney@CMU-CS-K	uucp:	seismo!cmu-cs-k!tim
CompuServe:	74176,1360	audio:	shout "Hey, Tim!"

Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[Bill Henneman]

Well, yes, FORTRAN is a more logical choice than LISP for crunching
numbers if thats *all* you're doing.  But suppose your application
involves 80% stuff where LISP routines are your best choice, but 20%
number crunching (an intelligent robot, for example, where the scene
analysis part would be a nightmare in FORTRAN, but the joint control
and the bit maps corresponding to the visual scene have heavy numerical
calculation).  I am not too proud to write an occasional SETQ, and I
might even stoop to writing a nested DO, if in return a get pattern
matching, and all those other goodies.

Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[Tim Maroney]

Ideally, if you are writing a program which has 80% "Lisp-like" code and 20%
"Fortran-like" code, the programming environment should make it possible to
link Fortran functions into the Lisp interpreter.  Unfortunately, many
(most?) Lisps do not support this....
-=-
Tim Maroney, Carnegie-Mellon University, Networking
ARPA:	Tim.Maroney@CMU-CS-K	uucp:	seismo!cmu-cs-k!tim
CompuServe:	74176,1360	audio:	shout "Hey, Tim!"

Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[Bill Henneman]

I don't share the same set of ideals.  I can link FORTRAN (or PASCAL, or
PL/I, or whatever) routines in our LISP.  I can even fire up
supprocesses written in strange languages, and pipe the answers back.
Should I?  I think not, possibly because I have a stronger belief in the
Whorfian hypothesis for programming languages than for natural
languages.  If I want to build a system, I don't want to have to switch
languages in mid-development.  Niggling little details about
representation switching start using up all my hacking time, which I
would rather devote to the application level.  Do you link SNOBOL
routines when you want pattern matching?  I bet not.  Should you,
ideally?  By your argument, yes.

I have had the distinctly unpleasant experience of trying to fix a DEC
internal system which was written in OPS5, but fired up tasks written in

	o	BASIC
	o	BLISS
	o	COBOL(!)

Anyone acting in the role of program doctor would have done what I did.
I prescribed euthinasia.

Multi-language systems

[Marty Sasaki]

> I have had the distinctly unpleasant experience of trying to fix a DEC
> internal system which was written in OPS5, but fired up tasks written in
> 
> 	o	BASIC
> 	o	BLISS
> 	o	COBOL(!)
> 
> Anyone acting in the role of program doctor would have done what I did.
> I prescribed euthinasia.

Why can't systems be written in multiple languages? Why can't you just
plug in the "correct" language for a certain part of a system? Is the
problem just the data-representation problem? Or is it more deeply
involved? Maybe the paradigms are sufficiently different in each
language that no human could be expert enough to handle more than one
language?

This seems like a problem that AI could solve. Programs, like the
various "programming apprentice" systems could do the mapping from one
data-representation to another. The paradigms are difficult, but work
has been done here too, hasn't it? (I really don't know since my main
interest is more software engineering rather than AI.)

DEC has gone through a lot of trouble to provide good compilers for the
various languages, why can't we take advantage of it?
-- 
-------------------------------------------------------------------------
  Marty Sasaki				net:   sasaki@harvard.{arpa,uucp}
  Havard University Science Center	phone: 617-495-1270
  One Oxford Street
  Cambridge, MA 02138

Re: Multi-language systems

[Tom Slack]

> > I have had the distinctly unpleasant experience of trying to fix a DEC
> > internal system which was written in OPS5, but fired up tasks written in
> > 
> > 	o	BASIC
> > 	o	BLISS
> > 	o	COBOL(!)
> > 
> > Anyone acting in the role of program doctor would have done what I did.
> > I prescribed euthinasia.
> 
> Why can't systems be written in multiple languages? Why can't you just
> plug in the "correct" language for a certain part of a system? Is the
> problem just the data-representation problem? Or is it more deeply
> involved? Maybe the paradigms are sufficiently different in each
> language that no human could be expert enough to handle more than one
> language?
> 
I strongly disagree with the first author.
Until programming languages get out of their own shells (no pun intended),
we will never have reasonably reusable software.
This is one of the reasons that UNIX pipes were invented.
I have recently (three years ago) gone through the process
of moving a LISP program (which I wrote) into PASCAL
through several intermediate stages where PASCAL routines
were called by LISP.
The original program in LISP was about 500 lines.
The current PASCAL implementation is about 3000 lines.
We discovered many details of importance to the application
itself which were hidden by the LISP implementation and
became apparent only after trying to code the problem in PASCAL.

Using LISP in this manner is distictively advantageous at times.
It can also have its difficulties.

The computer industry has just gone through a shake down it
deserved because each cpu believed that it was the center of
the world (hardware wise).
Personal computers are changing all that.
Unfortunately there are still people writing software
systems which want to take over the world (software wise).
Tom Slack
ittvax!wxlvax!slack

Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[Tim Maroney]

Don't start acting as if I had said "Whenever it is possible to link
code from another language into a Lisp system, you should do so."  I said
that if you were doing something numerically in Lisp which could be better
done by Fortran, then your Lisp system ought to make it possible to link in
the Fortran routines.  Representational problems are unlikely to be serious
when you are dealing with integers and reals on the same machine!  The worst
problem would be arrays, but a pair of conversion functions between the
representations should be near-trivial to write and debug, and once that is
done there is no problem.

No, I wouldn't advocate linking a SNOBOL program into one written in another
language, nor did I ever imply that I would.
-=-
Tim Maroney, Carnegie-Mellon University, Networking
ARPA:	Tim.Maroney@CMU-CS-K	uucp:	seismo!cmu-cs-k!tim
CompuServe:	74176,1360	audio:	shout "Hey, Tim!"

Fortran better than Lisp for numerical code?

[Barry Margolin]

There has been much discussion of late about comparing Lisp and Fortran
for numerical code.  Many people have either stated or implied that
Fortran should be better for number crunching than Lisp.  Why do people
believe that?  Why should a Fortran compiler produce any better code for
	A=B*C
than a Lisp compiler would produce for
	(setq a (* B C))
(assuming, in the latter case, appropriate declarations or use of
non-generic functions)?  Fortran is not a very complex language, but
neither is Lisp.  The only argument I can think of is that people assume
that Lisp compiler implementors would not bother optimizing the numeric
code, but would concentrate on the list processing code.  However, by
the time the compiler is doing much of its optimization (peephole,
register allocation) most of the distinction is gone.

In fact, many things in Lisp make it EASIER to optimize.  For instance,
in Fortran it is possible to jump into the middle of a DO loop from
outside the loop (I have a vague feeling that something like this was
declared invalid in Fortran-77, but there must be other similar
examples), while it is impossible to transfer into a Lisp do-loop.  This
means that less program analysis is necessary in order to produce very
good code for a loop in Lisp than Fortran.

The only other thing I can think of is that I don't know of any Lisp
implementations with double precision floating point (I suspect that
floating point was added to Lisp in the first place only grudgingly).
So, people that want more floating point precision should still use
Fortran (of course, if they want EXACT answers they should use Lisp with
bigna, which often have not only more precision but more range than most
floating point implementations).
-- 
    Barry Margolin
    ARPA: barmar@MIT-Multics
    UUCP: ..!genrad!mit-eddie!barmar

Speed of Lisp numerical code

[Stavros Macrakis]

WHEREAS it has become increasingly obvious that those discussing this
  issue on this list are unwilling to read each others' contributions
  carefully; and in particular
WHEREAS some persist in confusing a language design with its existing
  implementations and with its potential implementations; and 
WHEREAS Lisp advocates especially (on this list; on others, it's C or
  Pascal or Ada or APL advocates) fail to see weak points in their own
  systems and strong points in others'; and
WHEREAS it is likely that all those not participating in the discussion
  and most of those who are, are tired of it;

NOW THEREFORE, I hereby withdraw from the discussion of numerical
  efficiency in Lisp and
DO DECLINE to rebut comments on my earlier contributions while
  continuing to maintain their soundness.

NONETHELESS I am willing to receive and will study any substantive
  contributions to this question, such as documented benchmarks.

Re: Fortran better than Lisp for numerical code?

[T J Jardine]

> There has been much discussion of late about comparing Lisp and Fortran
> for numerical code.  Many people have either stated or implied that
> Fortran should be better for number crunching than Lisp.  Why do people
> believe that?  Why should a Fortran compiler produce any better code for
> 	A=B*C
> than a Lisp compiler would produce for
> 	(setq a (* B C))
> (assuming, in the latter case, appropriate declarations or use of
> non-generic functions)? ...

I won't try to speak about what others mean,  but I know that what I mean when
I say that Fortran is  "better"  for numeric computations has nothing to do at
all with  a=b*c  or its ilk.   Certainly  with appropriate attention to detail
Lisp can handle  (setq a (* b c))  with just as much efficiency.   Fortran (or
Pascal, ...)  is a more appropriate choice  if the numeric computations are at
a higher level,  such as  the computations  involved in  simulating the flight
dynamics of an air vehicle,  or in solving celestial navigation problems.   In
such a case  the optimum  is that  the problem solution already exists and one
must  "link"  to  the  solution  and  obtain  its results.  In a slightly less
optimal situation  a library of subroutines/functions  exists which need to be
coupled  in some  obvious  way  and  then  this  coupling "linked" to the Lisp
environment to obtain the solution.

The point is,  I believe, that just because we have Lisp, or a new "AI problem
solving approach"  does not mean that we should reinvent all problem solutions
using  this new approach.   Decision tables still provide an effective problem
solving tool for certain classes of problems  -- why not use such a capability
when it is applicable?   It may be the case  that other factors will influence
us to rewrite a solution using our new tool or approach -- I hope I don't ever
have  to write another  communications control program in COBOL,  for example,
although  COBOL  was indeed  capable of handling the particular problem at the
time.   By the way,  double precision  floating point  is the default in Franz
Lisp  (I haven't  yet found  a way to create a single precision variable,  but
haven't pursued it that far), and I know double precision is also available in
Zetalisp.   The  list  very  likely  larger than just those two -- Common Lisp
probably has it.

Ted Jardine
TJ (with Amazing Grace) The Piper
Boeing Artificial Intelligence Center
...uw-beaver!ssc-vax!bcsaic!ted
-- 
TJ (with Amazing Grace) The Piper
Boeing Artificial Intelligence Center
...uw-beaver!ssc-vax!bcsaic!ted

Re: Fortran better than Lisp for numerical code?

[Joe Orost]

Could we PLEASE keep the Fortran vs. Lisp debate out of net.lang.ada.  It
has nothing to do with Ada!
--joe

Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[Bill Henneman]

Um, I think I made a careless error.  I have been responding to messages
in net.ai without checking the cross-listings of the postings.  I
phrased my reply under the misapprehension that I was conversing with an
experienced LISP user.  My curt reply was based on a wrong model of how
elliptic I could be.  The only thing I accused you of was basing an
argument on experience you didn't have.  I'll start over.

If you say that PASCAL or ADA ought to be able to link FORTRAN library
routines, I'll interpret the statement as a comment about the benefits
gained from using carefully crafted library packages like the IMSL
routines vs. the cost of accommodating the linkage.  Any compiler builder
will agree - something like the support required has to be there, the
cost of accommodation is small, the benefit is great.  It ought to be
done.  

But LISP is not some sort of Cambridge Polish form of FORTRAN.  It makes
different assumptions about the computing environment.  LISP is
interpreted, and has a rather devil-may-care attitude about errors,
since it can inspect the entire run time environment to take corrective
action.  The FORTRAN compiler inserts certain implicit assumptions about
the run-time environment into compiled code, and refuses to compile
"dangerous-looking" code, because it can't see the run-time environment.

While most LISPs I am familiar with can load FORTRAN library routines,
none fully support them.  As a simple example of the difference between
allowing alien routines to be called and supporting their use, consider
the trivial problem of linking to SQRT from LISP.  This does involve a
trivial reformatting of numbers to support the call. No problem - float
the number if necessary, build the calling sequence and call SQRT.  But
what happens if SQRT detects what it thinks is an error condition (such
as a negative number being passed)?  Who gets to handle the problem?
SQRT assumes the presence of a fairly elaborate run-time support module
to handle error messages, and in this case to provide standard fix-ups.
Does the LISP user get a FORTRAN error message with the answer
canonically set to 0, or a LISP error break?  The only answer
acceptable to the LISP user is to be thrown into the LISP error break,
so the FORTRAN error handler has to be trapped by a special LISP module
to support the FORTRAN run-time routine.

Building such a beast is a non-trivial job, since you have to take into
account all the different ways FORTRAN routines might react to error
conditions.  Some FORTRAN library routines depend on interrupt handlers
being present, or specific interrupts being masked off.  Some FORTRAN
graphics library routines feel free to use the complete I/O capabilities
of the machine.  In fact, in order to provide LISP functions with the
ability to use the FORTRAN routines called, LISP ends up having to
simulate (and override) the full run-time environment of FORTRAN.  This
simulation is a complete add-on, since LISP treats all such
environmental issues in a completely different fashion.

And so, we come to my assertion that you might as well try to link
SNOBOL routines.  Well, if you have provided the full run-time support
for FORTRAN library routines, you get SNOBOL support essentially for
free!  Read "The Macro Implementation of SNOBOL 4" by Ralph E. Griswold
to see how much SNOBOL relies on the FORTRAN environment. 

In order to get the benefit, you have to pay the cost.  The cost in the
case of PASCAL supporting FORTRAN library routines is paid in how you
code a module which in some form or another had to be there anyway, and
the user sees nothing but benefits.  The cost in the case of LISP
supporting FORTRAN library routines is paid in designing a module which
allows things to be done in a way inconsistent with the way everything
else is done in LISP, leading to code which is difficult to maintain, an
interface which is impossible to document, and a very angry user
community.  It just isn't worth it.

Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[Norman Diamond]

> If I want to build a system, I don't want to have to switch
> languages in mid-development.  Niggling little details about
> representation switching start using up all my hacking time, which I
> would rather devote to the application level.

That's exactly why you do some planning in very early development (I will
need this routine in that language, so I will code it last and add an
assembly-language interface, or I will code it first and maybe / maybe not
need an assembly-language interface); and why you switch languages only at
the very end of development (when you are actually coding).

When I code a call to a subroutine, I do not suspend this routine and
immediately code the subroutine.  The subroutine is already written or
will be written later.  Language switching is even less frequent than
routine switching.

-- 

   Norman Diamond

UUCP:  {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond
CSNET: ndiamond%watdaisy@waterloo.csnet
ARPA:  ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa

"Opinions are those of the keyboard, and do not reflect on me or higher-ups."

Re: Common Lisp and Arrays

[Joaquim Martillo]

Having  just  seen a small program using arrays and structures in Common
Lisp turn into a moderaterately sized program because defstruct  created
copy-function  does  not fully copy the structure to which it is applied
but instead array-structure-members reference  the  same  array  as  the
original  structure to which the copy function was applied, I am willing
to believe arrays and structures in  Common  Lisp  were  designed  by  a
committee.   By the way testing arrays or structures for equality in the
equal sense is not possible using equal or any function of which I know.
Am  I  missing  something?   Having  powerful functions for manipulating
strings and lists and truly wimp-like functions for handling  structures
and arrays seems rather silly.

Yehoyaqim Martillo

Re: Thus spake the DoD...

[M.Fischer]

<>
In last years offerings to small business, DoD was seeking specifications
for lisp, prolog, forth filters for ada.  They noted some doubt in the
request that ada was up to `some' ai tasks (emphasis theirs).

Mike Fischer seismo!mcvax!ukc!mf1

Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[Stavros Macrakis]

I don't mean this to go on forever, but Maroney's gross distortion of my
point forces me to:

> That seems like some pretty dumb code to put in Lisp.  Iteration, setq --
> yech!  I don't think any person in their right mind would disagree that
> Fortran-like or Algol-like languages are far better suited to this style of
> programming than Lisp.
> Now, let's see you write a recursive linked-list program in Fortran, which
> doesn't have stack-based calling, pointers, or anything remotely like
> structured data types.... -- Tim.Maroney@CMU-CS-K

The point was simply that in fact MacLisp numeric code is not all that
it's cracked up to be, and indeed if you want efficient number-crunching
you use some other language.  Fortran happens to be the language in
terms of which the original argument was couched.  Given what I know of
the internals and the I/O behavior of both the Maclisp compiler and the
Intermetrics AIE Ada compiler (I work part-time there), I suspect that
it too will produce better numeric code but also non-numeric code
(including handling recursion, linked lists, etc.) than Maclisp.
Regrettably, garbage collection was not funded in the AIE.

Having worked with Lisp for 14 years now, I think I have some idea of
its strengths, which in my opinion are being diluted by pretending it is
just a general-purpose language with a funny syntax and poor
type-checking.

> The most sophisticated Lisps (such as Common Lisp) include a wealth of
> other datatypes intended for high efficiency in applications. -- shebs

Here's an example of the `wealth' of datatypes from a member of the
Common Lisp committee: "Common Lisp arrays are incredibly complex....
The resulting tangle of types...is clearly a political compromise and
not something that would exist after careful design". [RA Brooks and RP
Gabriel (an very experiencied Lisp implementer), "A Critique of Common
Lisp", 1984 ACM Symposium on Lisp and Func. Prog.; an excellent paper,
by the way]

>  For many years, the Maclisp compiler on the DEC-20 has produced
> numerical code superior to Fortran. -- stan shebs

This is not and never was true.  See my previous posting.  As for poor
Common Lisp, "it requires either specially micro-coded machines, a
fantastically complex compiler (which relies on copious declarations
from the poor incompetant user), or very slow running time." [ibid]

> There was an informal experiment done in the early-mid seventies at
> MIT [: a] translator was written to translate (say) FORTRAN into
> MACLISP....  In every case the lisp versions ran faster and took up
> less memory....  The programs being used were purely [numerical]. --
> sasaki@harvard

This is the same error being repeated.  Fateman's 1974 SIGSAM Notes
article seems to be the source.  There was exactly one example given,
and my previous posting discusses why it did well.

Indeed, Macsyma has both a Fortran-to-Lisp translator (written by Kent
Pitman) and a numerical-Fortran-code-generator.  They are both useful:
F-L to import numerical libraries into Lisp (unfortunately the runtime
conventions apparently clashed too much to allow Fortran code simply to
be linked in); Macsyma-F to use symbolic results to generate Fortran
programs which were then run on other machines.

Lisp is a wonderful language, but it has never run numbers fast.  It is
even less likely to run numbers, or anything else, fast, in its current
PL/I-like phase of development.

	-s

Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)

[Stanley Shebs]

In article <473@harvard.ARPA> Stavros Macrakis writes:

>The point was simply that in fact MacLisp numeric code is not all that
>it's cracked up to be, and indeed if you want efficient number-crunching
>you use some other language.  Fortran happens to be the language in
>terms of which the original argument was couched.  Given what I know of
>the internals and the I/O behavior of both the Maclisp compiler and the
>Intermetrics AIE Ada compiler (I work part-time there), I suspect that
>it too will produce better numeric code but also non-numeric code
>(including handling recursion, linked lists, etc.) than Maclisp.
>Regrettably, garbage collection was not funded in the AIE.
>
>Having worked with Lisp for 14 years now, I think I have some idea of
>its strengths, which in my opinion are being diluted by pretending it is
>just a general-purpose language with a funny syntax and poor
>type-checking.

There were a lot of people at AAAI that had worked with Lisp for a long
time and whose Lisps were beaten by PSL in the Gabriel timing tests.
Lisp is a sufficiently high-level language that implementation tricks
buy you a lot.  The problem seems to be that really efficient Lisp
requires so MANY tricks that it strains normal hacking practice to
include them all (thus my own research on accountable knowledge-based
implementations).

>Here's an example of the `wealth' of datatypes from a member of the
>Common Lisp committee: "Common Lisp arrays are incredibly complex....
>The resulting tangle of types...is clearly a political compromise and
>not something that would exist after careful design". [RA Brooks and RP
>Gabriel (an very experiencied Lisp implementer), "A Critique of Common
>Lisp", 1984 ACM Symposium on Lisp and Func. Prog.; an excellent paper,
>by the way]

Actually, I was just pointing out that real Lisps have more than
just integers, symbols, and pairs.  In any case, I think it's 
interesting that languages intended for many different uses get 
so large - PL/I, Common Lisp, Ada...  Everybody complains about
it, but I don't know that it's such a bad thing.  At least in CL,
90% of the hair can be coded using a simpler Lisp - the purpose
of the standard is just to ensure that everybody's utilities look
alike, and that portable programs don't need to carry 10,000 lines
of libraries around (including a 69th implementation of defstruct,
looping macros, formatting functions, ad nauseam).  CL is about the
same size and complexity as a PSL (which is generally considered 
to be a "small" Lisp) with all the loadable stuff brought in.

>>  For many years, the Maclisp compiler on the DEC-20 has produced
>> numerical code superior to Fortran. -- stan shebs
>
>This is not and never was true.  See my previous posting.  As for poor
>Common Lisp, "it requires either specially micro-coded machines, a
>fantastically complex compiler (which relies on copious declarations
>from the poor incompetant user), or very slow running time." [ibid]

I was wrong and I apologize if I misled anyone.  However, I personally
don't believe the statement about CL (except maybe the part about the 
compiler being complex!).  After all, didn't people used to believe 
that Lisp is inherently a very slow language?

>Lisp is a wonderful language, but it has never run numbers fast.  It is
>even less likely to run numbers, or anything else, fast, in its current
>PL/I-like phase of development.

The PSL group here has a pretty good compiler under development.  The
old PSL compiler (which did so well on the Gabriel timing tests) is
pretty crude by comparison...  We're also looking at ways to make
CL run as fast as PSL.

One final note:  an Ada person accusing Common Lisp of being too
big and complex is definitely a pot calling the kettle black.

						stan shebs

Thus spake the DoD...

[Frederick J Dickey]

[gourmet line eater snacks: * * * * *]

The DoD has announced its intention to make Ada the single, common,
computer language for Defense mission-critical applications. Presumably,
this means that if you have a Defense mission-critical application of AI, 
then you're going to program it in Ada. Is this reasonable? Is this
possible? Now I happen to work in an AI group of a large aerospace
company located in the general vicinity of Seattle, WA, so the answers
to these questions are of considerable interest to me. What do people
out there on the net think about this? Should AI people rush out and 
buy Ada manuals? Sell their Symbolics stock? Roll over and play dead?
Or what?

To help get this discussion off the ground, I am including three
hypothetical responses to my questions. 

-------------------------------------------------------------------------
HYPOTHETICAL RESPONSES
-------------------------------------------------------------------------

[response from Byron Kapse: I do all my AI programming in Ada. Lisp is an 
archaic dinosaur from the 50's. Ada is the language of the 80's. It's the 
first non-von Neumann language. It results from years of research into 
concepts that encourage and enforce good programming practices. Ada is the 
basis for a new culture of software engineering. The AI community can
definitely benefit from the discipline that results from the use of Ada.
The DoD is well advised to mandate the use of Ada for embedded applications, 
including embedded AI applications.]

[response from John McCadr: No way the DoD is going to use Ada for AI; they're
out of their minds. Give me one example of a significant AI system written in
Ada. It's is a von Neumann nightmare! Using Ada is like trying to brush 
your teeth with a strait jacket on. If you paid Ada programmers 5 cents a line 
to code Ada, they'd become millionaires. The DoD is going to have to admit 
that Lisp is the only way to go. Modern Lisp environments represent over 
thirty years of experience. We know how to do it. A programmer at a Lisp 
workstation like a Symbolics or LMI can blow the socks off any Ada programmer 
alive.]

[response from John Q. Programmer: Why can't we have our cake and eat it too? 
I have a product specification for a Lisp that is based upon Ada. Apparently, 
what this product does is take Lisp source code and translate it into Ada. 
So if the DoD says "do it in Ada," all you have to do is show them the 
translated code and they'll be happy while you can do your coding in Lisp. 
Besides that, this product allows you to combine the symbolic processing 
capability of Lisp with the number crunching capability of Ada. You get 
the best of both worlds! This really looks like the way to go.]