From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=BAYES_20,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!ames!xanth!kent From: kent@xanth.UUCP (Kent Paul Dolan) Newsgroups: comp.lang.ada Subject: Re: Adathink Message-ID: <2092@xanth.UUCP> Date: Thu, 13-Aug-87 12:17:19 EDT Article-I.D.: xanth.2092 Posted: Thu Aug 13 12:17:19 1987 Date-Received: Sat, 15-Aug-87 10:40:48 EDT References: <870806210856.08p@VLSI.JPL.NASA.GOV> <1844@bcsaic.UUCP> Reply-To: kent@xanth.UUCP (Kent Paul Dolan) Distribution: na Organization: Old Dominion University, Norfolk Va. Keywords: Ada, AI Summary: compiled = more efficient List-Id: 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!