dickey@ssc-vax.UUCP (Frederick J Dickey) (02/14/85)
[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.]
bob@sdcsvax.UUCP (Robert Hofkin) (02/17/85)
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.
hedrick@topaz.ARPA (Chuck Hedrick) (02/18/85)
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.
mf1@ukc.UUCP (M.Fischer) (02/19/85)
<> 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
djsalomon@watdaisy.UUCP (Daniel J. Salomon) (02/19/85)
> 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.
rmc@panda.UUCP (R. Mark Chilenskas) (02/21/85)
There are many, many, very times many directives by the DoD. The Ada directive mostly applies to "embedded systems", which is typically taken to mean operating systems, compilers, database systems, ... In addition, some other programs classically considered applications would be done in Ada as well. For AI research, expert systems, command and control systems using AI techniques, etc. the language of DoD choice is Common Lisp. There is a fair amount of effort (and even some money from DoD) going into standardization and insuring that all machines commonly used for DoD work in the above areas have a Common Lisp implementation. As a contractor, you are likely to need a waiver to program in some language other than Ada or Common Lisp, but as long as you choose one of the two you can probably justify it to your sponsor. R Mark Chilenskas decvax!genrad!panda!rmc
jans@mako.UUCP (Jan Steinman) (02/25/85)
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 ::::::
shebs@utah-cs.UUCP (Stanley Shebs) (02/27/85)
> >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
djsalomon@watdaisy.UUCP (Daniel J. Salomon) (02/27/85)
> 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.
david@daisy.UUCP (David Schachter) (02/28/85)
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 Schachtershebs@utah-cs.UUCP (Stanley Shebs) (03/01/85)
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
shebs@utah-cs.UUCP (Stanley Shebs) (03/01/85)
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
neves@uwai.UUCP (03/01/85)
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@uwvaxtmb@talcott.UUCP (Thomas M. Breuel) (03/02/85)
> 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.
martillo@mit-athena.UUCP (Joaquim Martillo) (03/03/85)
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
tjj@ssc-vax.UUCP (T J Jardine) (03/03/85)
> 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
jbn@wdl1.UUCP (03/05/85)
... ``Don't forget that LISP is a programming environment, not just a programming language.'' Indeed. One problem with LISP is that it is usually hard to separate out the completed program from the development environment and run it in a production environment; there is a strong built-in assumption in most LISP systems that the user wants all the programming tools available at all times. Some years ago, when Franz Lisp, which has a separate compiler that generates somewhat nonstandard .o files was being written, I asked one of the developers if it would be possible to link the .o files with a suitable library, rather than loading them into the Lisp image containing the reader, interpreter, the entire library, etc, so that only the library routines needed by the compiled code would be present. It was a sort of culture shock to him that anyone would ask such a question; the idea that one would want to run LISP programs without everything in the standard system present was totally alien to his way of thinking. But this is exactly what you want in embedded systems.
jans@mako.UUCP (Jan Steinman) (03/05/85)
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 ::::::
rap@oliven.UUCP (Robert A. Pease) (03/06/85)
. > 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
geb@cadre.UUCP (03/06/85)
>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?
holtz@clan.UUCP (Neal Holtz) (03/06/85)
Daniel Salomon raised the old issue of (supposed) Lisp inefficiency;
this has been answered well, many times, but ...
Following are some results of a quick comparison using the standard,
stupid recursive Fibonacci calculation, in 4 popular languages (yes,
even Fortran!). I know that this is not terribly relevant, but still
the results are interesting, and some might find them surprising.
They are presented at the end, so you don't have to read them (Lisp
wins, by the way -- Mr. Shebs is right, Portable Standard Lisp really
flies).
More importantly, I have recently been toying with a slightly more realistic
application -- critical path computations for project planning. I quickly
wrote a very nice, though minimal, implemention in PSL of the
"activity-on-node" model. Took 3 or 4 hours, occupies about 4 pages
of listing, does a lot of error and consistency checking, allows nice
(and minimal) input (i.e., for each activity you simply give its duration
and list of predecessors), and is very understandable (I think). It also
uses natural and easily extensible data structures, so it is very clear
how to extend this for more realistic modelling. For a 1000 activity network,
with an average of about 6 predecessors for each activity, on an 11/750,
it takes 40 CPU seconds to read in the data and construct
the network, and 90 seconds to compute early-start and late-finish time
for each activity (using extremely simple recursive algorithms 6 lines long).
I would be surprised if an equivalent C or Fortran program was significantly
faster. Even if they were, that would be largely irrelevant. A 1000
activity network is LARGE. 90 seconds of elapsed time on a personal
workstation is very easy to accept. It is unlikely that a tripling of speed
would ever pay for the increased implementation cost (particulary the
Fortran implementation cost).
---------
CPU time (in sec.) for avg. of 5 runs of fib(25) [= 121393]
(Optimizers turned on where possible)
Apollo DN320 Vax 11/750
Aegis 4.2 BSD
Fortran - 11.39 ?
C - 10.05 8.78 (cc -O)
Pascal - 8.09 10.88 (pc -O)
PS Lisp - 5.38 5.80
The uninteresting code follows:
% ************************* Portable Standard Lisp *************************
(BothTimes (load fast-arith fast-int))
(de fib (n)
(if (or (= n 0) (= n 1))
1
(+ (fib (- n 1)) (fib (- n 2)))
))
(de run ()
(let ((res (fib 25)))
(printf "Result is %w%n" res)
))
/* ************************* C ************************* */
long fib( n )
long n;
{
if( n == 0 || n == 1 )
return( 1 );
else
return( fib(n-1) + fib(n-2) );
}
main()
{
long res;
res = fib( 25 );
printf( "Result is %ld\n", res );
}
{ ************************* Pascal ************************* }
program fibi(output);
type integer32 = integer; { delete this line for Apollo }
var result : integer32;
function fib( n : integer32 ) : integer32;
begin
if (n = 0) or (n = 1) then
fib := 1
else
fib := fib( n-1 ) + fib( n-2 );
end;
begin
result := fib( 25 );
writeln( 'Result is ', result );
end.
C ************************* Fortran *************************
integer*4 res
integer*4 fib
res = fib( 25 )
write(*,*) 'Result is ',res
end
integer*4 function fib( n )
integer*4 n
if( (n .eq. 0) .or. (n .eq. 1) ) then
fib = 1
else
fib = fib( n-1 ) + fib( n-2 )
endif
endmarkh@rtech.ARPA (Mark Hanner) (03/07/85)
> ....there is a strong built-in assumption > in most LISP systems that the user wants all the programming tools available > at all times....the idea that one would want to run LISP > programs without everything in the standard system present was totally alien > to his way of thinking. this has to do with what many lisp programs end up doing. functions are built dynamically as lists in response to a non-deterministic human input for later execution. a lisp programmer would certainly like to assume that all of the functionality of his development system would be present at run time to be able to automate anything that might be done interactively. lisp is a different way of thinking than c (my home turf), as with apl, as with rpg2, as with quel, ad nauseum. use the proper tool for the task (no code generators in apl ;-)), but at least give us .o files that talk to each other... -- cheers, mark hanner (markh@rtech.ARPA) "there is a motorcycle in new mexico." -r.brautigan
hen@bu-cs.UUCP (Bill Henneman) (03/08/85)
I think it would be a *rare* piece of Lisp code that could be run without most of the functionality of LISP at run time: all of the implimentations I am familiar with ensure that anything that builds list structure funnel through a call to CONS. CONS uses an implicit assumption of a LISP garbage collector present when the CONS can't find space. But once you have the memory management routines (and all that they imply) resident at run time, you have come so close to having a LISP, you might as well throw in the rest (READ is the only other hairy thing to write). I have been faced with this issue in conjunction with an automatic code-porting project I have been working on this year; my current state is that I believe one can write systems to take code in any compiled language and produce equivalent LISP code, but that converting in the opposite direction is not economically feasible.
holtz@clan.UUCP (Neal Holtz) (03/09/85)
> 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 Two very good candidates are: 1. Winston, P.H., and Horn, B.K.P., (1984), "LISP - Second Edition", Addison Wesley. (Note that the second edition is much improved over the first). 2. Abelson, H., and Sussman, G.J., (1985) "Structure and Interpretation of Computer Programs", MIT Press. The second does not purport to teach Lisp, it just uses it to discuss important ideas in programming (it actually uses Scheme, a not generally available dialect, but in most cases that doesn't differ substantially). In spite of that (or perhaps because of it), it is still very usable to learn from. The first book is more traditional in that it explicitly sets out to teach Lisp (using Common Lisp, in this case), but does discuss many of the same ideas. In my opinion, you might find Winston and Horn a bit easier to learn from, but you really should have both. Its probably irrelevant now, but the one book that you should stay as far away from as possible, should you ever see it on the remaindered book shelves, is: 3. Tracton, Ken, (1980), "Programmer's Guide to LISP", No. 1045, TAB Books. I was deeply offended by this book; I know of no "better" way to discourage people from learning Lisp than to give them this to learn from. It is particularly unfortunate in that it is the type of book that would easily fall into the unwitting hands of the neophyte, being inexpensive and, on the surface, being simple to understand. It was obviously directed at the "home hacker" market, but it does a great injustice to those people. Almost none of the examples show the power of the language; most are straightforward numerical examples at which Lisp offers no obvious advantage. In the few examples that are more "lispy", there is no mention as to why you might want to do such a thing. The style of presenting programs is atrocious (e.g., no indentation to show structure). It is riddled with errors. On two separate occasions I have turned to pages at random (a total of 11) and found errors on all but one -- I usually quit looking after the first (page 89 was the only one on which I did not find any obvious errors). Sorry, Ken, if you read this, but the afternoon you spent writing the book and checking the proofs did not greatly advance the art and science of computer programming. - Neal Holtz Dept. of Civil Engineering Carleton University
walker@petrus.UUCP (03/11/85)
IJCAI-87 Officer Election and Site Selection The Trustees of the International Joint Conferences on Artificial Intelligence, Inc. are pleased to announce that Alan Bundy, University of Edinburgh, will be Conference Chair for IJCAI-87; John McDermott, Carnegie-Mellon University, will be Program Chair; and Milan will be the site, with Marco Somalvico of the University of Milan being responsible for Local Arrangements. The conference will be held 23-29 August 1987 (Sunday through Saturday).
walker@petrus.UUCP (03/11/85)
The site for IJCAI-89 will be selected at the IJCAI-85 in Los Angeles this summer (18-24 August). Proposals--for North American locations only (in accordance with the IJCAI practice of alternating between North America and other parts of the world; IJCAI-87 will be held in Milan, Italy)--should be sent by 1 August 1985 to Don Walker, IJCAII Secretary-Treasurer, Bell Communications Research, 435 South Street, Morristown, NJ 07960. Note that AAAI will cosponsor the conference and that the AAAI Office will coordinate local arrangements activities and support the local committee. Proposals should respond to the following criteria, which were developed by the IJCAII Trustees to govern site selection: 1. Local AI Group Support: strength of local AI activity; quality and breadth of the proposed local arrangements group; potential beneficial impact of an IJCAI on local activity. 2. Site Accessibility: ease of access for the international AI community via air and train transportation; convenient access to social centers. 3. Conference Facilities: ability to accommodate 5,000-10,000 people, with a hall for plenary sessions that can hold the full number and 5-6 rooms for 1,000-2,000 each. 4. Residences and Catering: a range of accommodations from dormitories to good quality hotels in sufficient quantities and proximity to the conference site; catering services for meals, breaks, banquets, and receptions are required. 5. Site Attractiveness: pleasantness of surrounding environment; local social and cultural attractions for attendees and families.
colbert@spp1.UUCP (Ed Colbert) (03/12/85)
>... 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
macrakis@harvard.ARPA (Stavros Macrakis) (03/12/85)
> Following are some results of a quick comparison using the standard, > stupid recursive Fibonacci calculation, in 4 popular languages (yes, > even Fortran!). I know that this is not terribly relevant, ... Yes, well, it is probably a good measurement of procedure call overhead on the implementations you tested. Presumably some programs spend a significant amount of time doing something other than procedure calling. It is never surprising to find that a program written in one programming idiom (Lisp: heavily recursive; Fortran: nested iterations; APL: all the work in the operators) does better in its native language than if translated naively into another, not because the language necessarily `is better' in some abstract sense for that sort of problem, but rather that the implementation effort has been concentrated on efficient implementation of those features considered central. How many Lisp compilers can compile "do 10 i=1,10; do 10 j=1,10; 10 a(i,j)=2*x; into something efficient? Probably none; of course they <could>, but no one has bothered to worry about those cases. By the way, the VERY FIRST Fortran compiler (1958?) both extracted the 2*x from the loop and expanded this into a single loop.... As for the Critical Path calculations, good! Nice to get a useful result quickly. I'm not sure what it proves, though. -s
dk@browngr.UUCP (David Kantrowitz) (03/13/85)
I don't understand. I thought the idea was to make a lisp archive file and whenever you want to create an executable lisp program, link in the appropriate routines from the library. What difference should it make that you are using 70% of the routines in the library? Actually, this way you can put many more things into the library than the average lisp (things that the Lisp user now has to specifically 'load to get). It's not as if linking takes very long, especially in comparison to loading compiled code *into* lisp.
mmt@talcott.UUCP (Monique M Taylor) (03/13/85)
> > > >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 ***
jans@mako.UUCP (Jan Steinman) (03/17/85)
>>>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 ::::::
faustus@ucbcad.UUCP (03/21/85)
> >>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