* LISP &c (re: the DoD...)
1985-02-19 19:09 ` Daniel J. Salomon
@ 1985-02-22 2:21 ` Thomas M. Breuel
1985-02-25 17:08 ` Thus spake the DoD Jan Steinman
` (5 subsequent siblings)
6 siblings, 0 replies; 47+ messages in thread
From: Thomas M. Breuel @ 1985-02-22 2:21 UTC (permalink / raw)
> 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-02-19 19:09 ` Daniel J. Salomon
1985-02-22 2:21 ` LISP &c (re: the DoD...) Thomas M. Breuel
@ 1985-02-25 17:08 ` Jan Steinman
1985-02-26 23:20 ` Stanley Shebs
` (4 subsequent siblings)
6 siblings, 0 replies; 47+ messages in thread
From: Jan Steinman @ 1985-02-25 17:08 UTC (permalink / raw)
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 ::::::
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-02-19 19:09 ` Daniel J. Salomon
1985-02-22 2:21 ` LISP &c (re: the DoD...) Thomas M. Breuel
1985-02-25 17:08 ` Thus spake the DoD Jan Steinman
@ 1985-02-26 23:20 ` Stanley Shebs
1985-02-27 19:22 ` Daniel J. Salomon
` (2 more replies)
1985-03-12 0:25 ` Efficiency of LISP Stavros Macrakis
` (3 subsequent siblings)
6 siblings, 3 replies; 47+ messages in thread
From: Stanley Shebs @ 1985-02-26 23:20 UTC (permalink / raw)
>
>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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-02-26 23:20 ` Stanley Shebs
@ 1985-02-27 19:22 ` Daniel J. Salomon
1985-03-01 19:30 ` Stanley Shebs
` (4 more replies)
1985-02-28 3:16 ` David Schachter
1985-03-13 19:35 ` Monique M Taylor
2 siblings, 5 replies; 47+ messages in thread
From: Daniel J. Salomon @ 1985-02-27 19:22 UTC (permalink / raw)
> 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-02-27 19:22 ` Daniel J. Salomon
@ 1985-03-01 19:30 ` Stanley Shebs
1985-03-01 20:13 ` neves
` (3 subsequent siblings)
4 siblings, 0 replies; 47+ messages in thread
From: Stanley Shebs @ 1985-03-01 19:30 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-02-27 19:22 ` Daniel J. Salomon
1985-03-01 19:30 ` Stanley Shebs
@ 1985-03-01 20:13 ` neves
1985-03-02 4:33 ` Thomas M. Breuel
` (2 subsequent siblings)
4 siblings, 0 replies; 47+ messages in thread
From: neves @ 1985-03-01 20:13 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-02-27 19:22 ` Daniel J. Salomon
1985-03-01 19:30 ` Stanley Shebs
1985-03-01 20:13 ` neves
@ 1985-03-02 4:33 ` Thomas M. Breuel
1985-03-02 18:35 ` Efficiency of LISP Marty Sasaki
1985-03-03 0:23 ` Language criticism Greg Davidson
1985-03-06 14:13 ` Thus spake the DoD geb
4 siblings, 1 reply; 47+ messages in thread
From: Thomas M. Breuel @ 1985-03-02 4:33 UTC (permalink / raw)
> 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Efficiency of LISP
1985-03-02 4:33 ` Thomas M. Breuel
@ 1985-03-02 18:35 ` Marty Sasaki
0 siblings, 0 replies; 47+ messages in thread
From: Marty Sasaki @ 1985-03-02 18:35 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Language criticism
1985-02-27 19:22 ` Daniel J. Salomon
` (2 preceding siblings ...)
1985-03-02 4:33 ` Thomas M. Breuel
@ 1985-03-03 0:23 ` Greg Davidson
1985-03-06 14:13 ` Thus spake the DoD geb
4 siblings, 0 replies; 47+ messages in thread
From: Greg Davidson @ 1985-03-03 0:23 UTC (permalink / raw)
<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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-02-27 19:22 ` Daniel J. Salomon
` (3 preceding siblings ...)
1985-03-03 0:23 ` Language criticism Greg Davidson
@ 1985-03-06 14:13 ` geb
4 siblings, 0 replies; 47+ messages in thread
From: geb @ 1985-03-06 14:13 UTC (permalink / raw)
>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?
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-02-26 23:20 ` Stanley Shebs
1985-02-27 19:22 ` Daniel J. Salomon
@ 1985-02-28 3:16 ` David Schachter
1985-03-01 19:00 ` Stanley Shebs
` (2 more replies)
1985-03-13 19:35 ` Monique M Taylor
2 siblings, 3 replies; 47+ messages in thread
From: David Schachter @ 1985-02-28 3:16 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-02-28 3:16 ` David Schachter
@ 1985-03-01 19:00 ` Stanley Shebs
1985-03-03 3:08 ` Joaquim Martillo
1985-03-03 6:12 ` T J Jardine
2 siblings, 0 replies; 47+ messages in thread
From: Stanley Shebs @ 1985-03-01 19:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-02-28 3:16 ` David Schachter
1985-03-01 19:00 ` Stanley Shebs
@ 1985-03-03 3:08 ` Joaquim Martillo
1985-03-03 6:12 ` T J Jardine
2 siblings, 0 replies; 47+ messages in thread
From: Joaquim Martillo @ 1985-03-03 3:08 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-02-28 3:16 ` David Schachter
1985-03-01 19:00 ` Stanley Shebs
1985-03-03 3:08 ` Joaquim Martillo
@ 1985-03-03 6:12 ` T J Jardine
1985-03-05 16:55 ` Jan Steinman
` (2 more replies)
2 siblings, 3 replies; 47+ messages in thread
From: T J Jardine @ 1985-03-03 6:12 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-03-03 6:12 ` T J Jardine
@ 1985-03-05 16:55 ` Jan Steinman
1985-03-05 21:07 ` Robert A. Pease
1985-03-12 1:47 ` Ed Colbert
2 siblings, 0 replies; 47+ messages in thread
From: Jan Steinman @ 1985-03-05 16:55 UTC (permalink / raw)
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 ::::::
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-03-03 6:12 ` T J Jardine
1985-03-05 16:55 ` Jan Steinman
@ 1985-03-05 21:07 ` Robert A. Pease
1985-03-12 1:47 ` Ed Colbert
2 siblings, 0 replies; 47+ messages in thread
From: Robert A. Pease @ 1985-03-05 21:07 UTC (permalink / raw)
.
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Thus spake the DoD...
1985-03-03 6:12 ` T J Jardine
1985-03-05 16:55 ` Jan Steinman
1985-03-05 21:07 ` Robert A. Pease
@ 1985-03-12 1:47 ` Ed Colbert
2 siblings, 0 replies; 47+ messages in thread
From: Ed Colbert @ 1985-03-12 1:47 UTC (permalink / raw)
>... 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Re: Thus spake the DoD...
1985-02-26 23:20 ` Stanley Shebs
1985-02-27 19:22 ` Daniel J. Salomon
1985-02-28 3:16 ` David Schachter
@ 1985-03-13 19:35 ` Monique M Taylor
1985-03-17 19:49 ` Jan Steinman
2 siblings, 1 reply; 47+ messages in thread
From: Monique M Taylor @ 1985-03-13 19:35 UTC (permalink / raw)
> >
> >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 ***
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Re: Thus spake the DoD...
1985-03-13 19:35 ` Monique M Taylor
@ 1985-03-17 19:49 ` Jan Steinman
1985-03-21 1:17 ` faustus
0 siblings, 1 reply; 47+ messages in thread
From: Jan Steinman @ 1985-03-17 19:49 UTC (permalink / raw)
>>>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 ::::::
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Re: Re: Thus spake the DoD...
1985-03-17 19:49 ` Jan Steinman
@ 1985-03-21 1:17 ` faustus
0 siblings, 0 replies; 47+ messages in thread
From: faustus @ 1985-03-21 1:17 UTC (permalink / raw)
> >>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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Efficiency of LISP
1985-02-19 19:09 ` Daniel J. Salomon
` (2 preceding siblings ...)
1985-02-26 23:20 ` Stanley Shebs
@ 1985-03-12 0:25 ` Stavros Macrakis
1985-03-12 2:11 ` Efficiency of numerical Lisp code (details) Stavros Macrakis
` (2 subsequent siblings)
6 siblings, 0 replies; 47+ messages in thread
From: Stavros Macrakis @ 1985-03-12 0:25 UTC (permalink / raw)
> > > 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Efficiency of numerical Lisp code (details)
1985-02-19 19:09 ` Daniel J. Salomon
` (3 preceding siblings ...)
1985-03-12 0:25 ` Efficiency of LISP Stavros Macrakis
@ 1985-03-12 2:11 ` Stavros Macrakis
1985-03-13 7:05 ` Chuck Hedrick
1985-03-13 20:00 ` Speed with numbers: PDP-10 Maclisp vs. Fortran (details) Stavros Macrakis
6 siblings, 0 replies; 47+ messages in thread
From: Stavros Macrakis @ 1985-03-12 2:11 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Efficiency of numerical Lisp code (details)
1985-02-19 19:09 ` Daniel J. Salomon
` (4 preceding siblings ...)
1985-03-12 2:11 ` Efficiency of numerical Lisp code (details) Stavros Macrakis
@ 1985-03-13 7:05 ` Chuck Hedrick
1985-03-13 20:00 ` Speed with numbers: PDP-10 Maclisp vs. Fortran (details) Stavros Macrakis
6 siblings, 0 replies; 47+ messages in thread
From: Chuck Hedrick @ 1985-03-13 7:05 UTC (permalink / raw)
> 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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Speed with numbers: PDP-10 Maclisp vs. Fortran (details)
1985-02-19 19:09 ` Daniel J. Salomon
` (5 preceding siblings ...)
1985-03-13 7:05 ` Chuck Hedrick
@ 1985-03-13 20:00 ` Stavros Macrakis
1985-03-14 10:12 ` Tim Maroney
6 siblings, 1 reply; 47+ messages in thread
From: Stavros Macrakis @ 1985-03-13 20:00 UTC (permalink / raw)
> [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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)
1985-03-13 20:00 ` Speed with numbers: PDP-10 Maclisp vs. Fortran (details) Stavros Macrakis
@ 1985-03-14 10:12 ` Tim Maroney
1985-03-15 0:27 ` Bill Henneman
0 siblings, 1 reply; 47+ messages in thread
From: Tim Maroney @ 1985-03-14 10:12 UTC (permalink / raw)
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!"
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)
1985-03-14 10:12 ` Tim Maroney
@ 1985-03-15 0:27 ` Bill Henneman
1985-03-16 0:59 ` Tim Maroney
0 siblings, 1 reply; 47+ messages in thread
From: Bill Henneman @ 1985-03-15 0:27 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)
1985-03-15 0:27 ` Bill Henneman
@ 1985-03-16 0:59 ` Tim Maroney
1985-03-17 18:58 ` Bill Henneman
1985-03-18 3:01 ` Common Lisp and Arrays Joaquim Martillo
0 siblings, 2 replies; 47+ messages in thread
From: Tim Maroney @ 1985-03-16 0:59 UTC (permalink / raw)
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!"
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)
1985-03-16 0:59 ` Tim Maroney
@ 1985-03-17 18:58 ` Bill Henneman
1985-03-18 5:02 ` Multi-language systems Marty Sasaki
` (2 more replies)
1985-03-18 3:01 ` Common Lisp and Arrays Joaquim Martillo
1 sibling, 3 replies; 47+ messages in thread
From: Bill Henneman @ 1985-03-17 18:58 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Multi-language systems
1985-03-17 18:58 ` Bill Henneman
@ 1985-03-18 5:02 ` Marty Sasaki
1985-03-20 17:01 ` Tom Slack
1985-03-18 21:24 ` Speed with numbers: PDP-10 Maclisp vs. Fortran (details) Tim Maroney
1985-03-19 3:40 ` Norman Diamond
2 siblings, 1 reply; 47+ messages in thread
From: Marty Sasaki @ 1985-03-18 5:02 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Multi-language systems
1985-03-18 5:02 ` Multi-language systems Marty Sasaki
@ 1985-03-20 17:01 ` Tom Slack
0 siblings, 0 replies; 47+ messages in thread
From: Tom Slack @ 1985-03-20 17:01 UTC (permalink / raw)
> > 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)
1985-03-17 18:58 ` Bill Henneman
1985-03-18 5:02 ` Multi-language systems Marty Sasaki
@ 1985-03-18 21:24 ` Tim Maroney
1985-03-19 6:45 ` Fortran better than Lisp for numerical code? Barry Margolin
1985-03-19 16:15 ` Speed with numbers: PDP-10 Maclisp vs. Fortran (details) Bill Henneman
1985-03-19 3:40 ` Norman Diamond
2 siblings, 2 replies; 47+ messages in thread
From: Tim Maroney @ 1985-03-18 21:24 UTC (permalink / raw)
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!"
^ permalink raw reply [flat|nested] 47+ messages in thread
* Fortran better than Lisp for numerical code?
1985-03-18 21:24 ` Speed with numbers: PDP-10 Maclisp vs. Fortran (details) Tim Maroney
@ 1985-03-19 6:45 ` Barry Margolin
1985-03-19 17:35 ` Speed of Lisp numerical code Stavros Macrakis
1985-03-20 21:04 ` Fortran better than Lisp for numerical code? T J Jardine
1985-03-19 16:15 ` Speed with numbers: PDP-10 Maclisp vs. Fortran (details) Bill Henneman
1 sibling, 2 replies; 47+ messages in thread
From: Barry Margolin @ 1985-03-19 6:45 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Speed of Lisp numerical code
1985-03-19 6:45 ` Fortran better than Lisp for numerical code? Barry Margolin
@ 1985-03-19 17:35 ` Stavros Macrakis
1985-03-20 21:04 ` Fortran better than Lisp for numerical code? T J Jardine
1 sibling, 0 replies; 47+ messages in thread
From: Stavros Macrakis @ 1985-03-19 17:35 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Fortran better than Lisp for numerical code?
1985-03-19 6:45 ` Fortran better than Lisp for numerical code? Barry Margolin
1985-03-19 17:35 ` Speed of Lisp numerical code Stavros Macrakis
@ 1985-03-20 21:04 ` T J Jardine
1985-03-22 2:10 ` Joe Orost
1 sibling, 1 reply; 47+ messages in thread
From: T J Jardine @ 1985-03-20 21:04 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)
1985-03-18 21:24 ` Speed with numbers: PDP-10 Maclisp vs. Fortran (details) Tim Maroney
1985-03-19 6:45 ` Fortran better than Lisp for numerical code? Barry Margolin
@ 1985-03-19 16:15 ` Bill Henneman
1 sibling, 0 replies; 47+ messages in thread
From: Bill Henneman @ 1985-03-19 16:15 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)
1985-03-17 18:58 ` Bill Henneman
1985-03-18 5:02 ` Multi-language systems Marty Sasaki
1985-03-18 21:24 ` Speed with numbers: PDP-10 Maclisp vs. Fortran (details) Tim Maroney
@ 1985-03-19 3:40 ` Norman Diamond
2 siblings, 0 replies; 47+ messages in thread
From: Norman Diamond @ 1985-03-19 3:40 UTC (permalink / raw)
> 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."
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Common Lisp and Arrays
1985-03-16 0:59 ` Tim Maroney
1985-03-17 18:58 ` Bill Henneman
@ 1985-03-18 3:01 ` Joaquim Martillo
1 sibling, 0 replies; 47+ messages in thread
From: Joaquim Martillo @ 1985-03-18 3:01 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 47+ messages in thread