dickey@ssc-vax.UUCP (Frederick J Dickey) (02/15/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.
g-frank@gumby.UUCP (02/17/85)
> I have a product specification for a Lisp that is based upon Ada. Apparently, > what this product does is take Lisp source code and translate it into Ada. > So if the DoD says "do it in Ada," all you have to do is show them the > translated code and they'll be happy while you can do your coding in Lisp. Real unlikely, guy. The whole point of Ada was that the DoD was tired of supporting the creation and maintenance of code in several hundred different languages. If your package was WRITTEN in Lisp, and is MAINTAINED in Lisp, I don't think DoD will care if you can mechanically translate it into Swahili. It won't be acceptable. -- Dan Frank Q: What's the difference between an Apple MacIntosh and an Etch-A-Sketch? A: You don't have to shake the Mac to clear the screen.
skef@cmu-cs-spice.ARPA (Skef Wholey) (02/18/85)
The major figures in the Common Lisp world are currently working closely with ARPA to establish a sort of "standards organization" for Common Lisp. Folks at ARPA are very interested in having Common Lisp become the required language for DoD AI work. The biggest obstacle to Common Lisp becoming such a standard at this point is Xerox and Interlisp community, not the Ada folks. -- uucp: ...!seismo!cmu-cs-spice!skef arpa: skef@CMU-CS-Spice
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.
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
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?
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
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