Diagramming Robust AI

Dave Kenny dk at parka.winternet.com
Mon Mar 30 13:19:30 EST 1998

In comp.lang.forth Phil Roberts, Jr. <philrob at ix.netcom.com> wrote:
: reflection on one of my FORTH books which describes it as a 
: language for writing languages and the only one which was written 
: in itself.  Thanks for your info. Interesting.

Hmm.  I see this (^^) more as Forth's ability to shape itself
around your application, so that your application itself becomes
a nicely integrated programming language instead of a grab-bag
of "API" routines.

Part of this is due to Forth's enormous flexibility, but part is
also due to Forth's tendency to make one write code that is both
more cleanly and finely (as in granularity) factored.

This approach tends to yield more distinct functions that can be
more flexibly combined than otherwise.  As Leo Brodie said in
one of his books (Thinking Forth?):

	Don't bury your tools.

He also had a cartoon of an enormous vending machine thing called
the EggMaster Object (or something similar) with several pushbuttons
for softBoiled, hardBoiled, poached, benedict, etc.  (I'm making up
these names 'cause I do not have the book here.)  The machine is
plastered with warnings "Keep out", "Authorized Personnel Only" etc.
There is a perplexed potential cusomer standing in front of the
machine asking

	"What, no scrambled?"

Classical software devlopment assumes that all the needs can be
anticipated at design time.  Using systems developed this way can
be a MAJOR pain.  Many "GraphicalUserInterfaces" are really
"CaptiveUserInterfaces" where the user is held hostage.  (I don't
recall the attribution for this, except that it was from a book
on the "unix philosophy" or "25 years of unix" or one of those sorts.)

That's part of why an application that is essentially a language
is so nice.


In Forth it is sometimes hard to write a couple of lines of code,
but if you do it right and test it immediately (which Forth
supports very nicely), that code has a very high liklihood of
working correctly, so from then on it's a reliable building block,
and all you ever look at (usually) is its stack comment and one-line

Other languages make it relatively easy to churn out tons of
_correct-looking_ code quickly, but because one can be sloppier,
there's a greater chance for errors, and the errors can be spread
out over a larger functional unit, so they are harder to identify,
and thorough testing is more difficult.

More information about the Neur-sci mailing list