Adathink

Adathink

[PETCHER%SVDSD]

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.

Re: Adathink

[blackje%sungod.tcpip]

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

	

Adathink

[larry]

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-vlsi

Re: Adathink

[Ted Jardine]

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

Re: Adathink

[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!