larry@VLSI.JPL.NASA.GOV (08/07/87)
As for as self-modifying code is concerned, I think those who've
done "AI-type" products find that very little code of this sort
is needed or desirable. This is one reason why compilable LisP
is such a useful tool. Self-referencing can also be done in
other ways than self-modifying code.
The relation between AI languages and Ada/C/etc. seems to be that
LisP/Smalltalk/etc. are very effective for exploratory pro-
gramming and prototyping, but when a system is to be delivered
it's best to translate it to a compiled language first.
As for control structures, this is a subject I'd like to see some
advice on too. I'm writing an EMACS like text-processor and I'll
admit that I'm having problems with the over-all architecture.
(Maybe because I've been immersed for the past few months in C
code for several EMACSes and my perceptions have been corrupted!)
Larry @ jpl-vlsiPETCHER%SVDSD@eg.ti.COM (08/07/87)
I talked to some folks a while back who were doing algorithm design and testing in LISP then converting to JOVIAL for actual implementation. They claimed to be experiencing extremely high productivity using this method. In playing with LISP myself I found that, inspite of its striking dissimilarity from any "conventional" (procedural?) language, thinking out a process in LISP gave me a much clearer picture of how to think about that process regardless of language. Malcolm Petcher Texas Instruments, Inc.
blackje%sungod.tcpip@ge-crd.arpa (08/08/87)
Received: by sungod.steinmetz (3.2/1.1x Steinmetz) id AA01240; Fri, 7 Aug 87 19:00:41 EDT Date: Fri, 7 Aug 87 19:00:41 EDT From: emmett black <blackje@sungod> Posted-Date: Fri, 7 Aug 87 19:00:41 EDT Message-Id: <8708072300.AA01240@sungod.steinmetz> To: PETCHER%SVDSD@eg.ti.com@relay.cs.net Subject: Re: Adathink Cc: info-ada@ada20.isi.edu > From: PETCHER%SVDSD%eg.ti.com@RELAY.CS.NET > Malcolm Petcher > > I talked to some folks a while back who were doing algorithm design and > testing in LISP then converting to JOVIAL for actual implementation. They > claimed to be experiencing extremely high productivity using this method. In > playing with LISP myself I found that, inspite of its striking dissimilarity > from any "conventional" (procedural?) language, thinking out a process in LISP > gave me a much clearer picture of how to think about that process regardless > of language. Funniest thing... the entire IAW (Interactive Ada Workstation) is prototyped in LISP! --Emmett BlackJE@GE-CRD.Ada ...!steinmetz!crd!blackje
ted@bcsaic.UUCP (Ted Jardine) (08/11/87)
In article <870806210856.08p@VLSI.JPL.NASA.GOV> larry@VLSI.JPL.NASA.GOV writes: >As for as self-modifying code is concerned, I think those who've done "AI-type" >products find that very little code of this sort is needed or desirable. This >is one reason why compilable LisP is such a useful tool. Self-referencing can >also be done in other ways than self-modifying code. > >The relation between AI languages and Ada/C/etc. seems to be that LisP/ >Smalltalk/etc. are very effective for exploratory programming and prototyping, >but when a system is to be delivered it's best to translate it to a compiled >language first. > >As for control structures, this is a subject I'd like to see some advice on >too. ... As one who has been developing AI applications for the past several years, I am very interested in the topic expressed here. There is a class of AI system that does not involve self-modification. Its members are primarily advisory or consultant programs on very well defined problem domains. There are probably lots of instances where such systems might be useful, but they don't address complex problems. The majority of AI applications require that the system learn, both in the sense of modifying its knowledge-base (or data base) and in the sense of modifying its problem solving capabilities. Learning in the first sense doesn't require self-modifying code. Learning in the second sense may require self-modifying code, but at the very least will surely require that new control structures and control techniques be capable of being created by the system. The set of control structures provided in Ada, C, etc. have been shown to be sufficient for the construction of algorithmic solutions to problems under a set of assumptions. These assumptions are seldom, if ever, stated explicitly, but I believe that among them is at least the exclusive use of the Von Neuman architecture machine. I know of no proof that the 'structured programming' set of control structures is not sufficient, but it seems very likely that there is more to the universe than just these. Why do people believe that translation to a compiled language, or a language such as Ada is essential for a 'delivered' system? I am honestly interested in other people's views and experiences, even though my expectations lead me to believe that such translation is far less important than the creation of a solution to a complex problem. Please put your nickels on the table, I think we can all benefit. TJ {With Amazing Grace} The Piper (aka Ted Jardine) CFI-ASME/I Usenet: ...uw-beaver!ssc-vax!bcsaic!ted CSNet: ted@boeing.com -- TJ {With Amazing Grace} The Piper (aka Ted Jardine) CFI-ASME/I Usenet: ...uw-beaver!ssc-vax!bcsaic!ted CSNet: ted@boeing.com
kent@xanth.UUCP (Kent Paul Dolan) (08/13/87)
In article <1844@bcsaic.UUCP> ted@bcsaic.UUCP (Ted Jardine) writes: >In article <870806210856.08p@VLSI.JPL.NASA.GOV> >larry@VLSI.JPL.NASA.GOV writes: >>[...] The relation between AI languages and Ada/C/etc. seems to be >>that LisP/ Smalltalk/etc. are very effective for exploratory >>programming and prototyping, but when a system is to be delivered it's >>best to translate it to a compiled language first. [...] >[...]I know of no proof that the 'structured programming' set of >control structures is not sufficient, but it seems very likely that >there is more to the universe than just these. Why do people believe >that translation to a compiled language, or a language such as Ada is >essential for a 'delivered' system? I am honestly interested in other >people's views and experiences, even though my expectations lead me to >believe that such translation is far less important than the creation >of a solution to a complex problem. Please put your nickels on the >table, I think we can all benefit. I'd just like to pass on a couple of experiences here, because this blind spot seems pretty wide spread. In 1977, I was involved in the design of a cartographic data application network. As part of the effort, a NASA Ames PhD type (Hi, Andy!) showed up and designed a network simulation to see how many cpu's it would take to support ten work stations. NASA had (at the time, in some offices) standardized on BASIC for programming, which is perfectly suitable for one shot, loop free programs. So the simulation was done in BASIC, and ran for 14 HOURS per parameterization, with an ARPAnet connection hanging on overnight while the program ran to completion. Andy wanted lots of parameterizations, so he asked me to rewrite the network simulation in FORTRAN (this was how I learned BASIC - backwards ;-). I did so, and the simulation for one parameterization ran to completion in 30 SECONDS. Last year, I was briefly a systems programmer for our school's VAX with 4.3BSD Unix(tm). A professor (Hi, Chris!) in an AI class gave the students the task of finding the solutions for the plastic slide puzzle (numbers 1 to 15, plus a space, in a 4 by 4 square array) we all used as kids, by depth first search. The language in use was LISP. To make the problem feasable at all, it was reduced to 1 to 8 in a three by three square. One student was unable to believe his program wasn't stuck in a loop, and so scheduled a trace to the line printer, 9999 PAGES to a moving head dot matrix printer. Six others scheduled their jobs to run all at once, and tied up the system with load averages above 4.5 for ona and on-half DAYS, while their programs slowly ground to completion. I lost my cool a bit, and got a statement of the problem, then solved it in C (absolutely my least favorite language among the four dozen I know, but it was available, compiled, and could be expected to be known to both the professor and his students.) The problem ran to completion and found the solution in two and one half MINUTES. One premier reason to deliver a solution in a compiled, closed form, is that it makes use of the solution reasonable for the users. When you work in an interpreted language environment (which I do at home, with AmigaBASIC (yuch!)) you lose track of how much you're giving away in performance. IF AI in LISP is all you evr do, you may not know any better at all, as seems to be the case here. Most folks worrying about language performace are arguing about a twenty percent difference between execution speeds of code produced by various compilers; the examples I have shown above are typical of the twenty to hundredfold difference in execution speeds between compiled and interpreted languages, and that is another matter entirely. I can't speak for the commercial LISPs, but compiling Franz LISP gives a performance improvement of only three to one, for the three or four (fairly large) programs I have written and bothered to compile in Franz LISP. Until a LISP is in circulation that gives performance comparable even to Ada, which, in its present stage of evolution, is one of the slower compiled imperative languages, the advice given to translate the problem to a compiled language before delivery is probably excellent. (Parenthetically, I think most self modifying programs could be rethought to modify data rather than code, but I'm sure I wouldn't have the expertise to do it, and it might require the equivalent loss in speed to program interpretation, anyway.) Kent, the man from xanth. -- Kent Paul Dolan, LCDR, NOAA, Retired; ODU MSCS grad student // Yet UUCP : kent@xanth.UUCP or ...{sun,harvard}!xanth!kent // Another CSNET : kent@odu.csnet ARPA : kent@xanth.cs.odu.edu \\ // Happy USPost: P.O. Box 1559, Norfolk, Virginia 23501-1559 \// Amigan! Voice : (804) 587-7760 -=][> Last one to Ceres is a rotten egg! -=][> I code reactor power plant control in C. I add "count_of_recent_alarms" to "count_of_rods_to_lift". C has weak type checking; the compiler doesn't notice. A major coolant valve sticks, a spate of alarms occur. All die. Oh, the embarrassment!