Re: Adathink

[kent@xanth.UUCP (Kent Paul Dolan)]

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!