Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uwm.edu!csd4.csd.uwm.edu!wlee
From: wlee@csd4.csd.uwm.edu (Wan Ngai Wayne Lee)
Newsgroups: comp.robotics
Subject: Re: "Easy" way to put "AI" in realtime embedded systems?
Message-ID: <11114@uwm.edu>
Date: 18 Apr 91 02:46:27 GMT
Sender: news@uwm.edu
Distribution: usa
Organization: University of Wisconsin - Milwaukee
Lines: 33
Originator: wlee@csd4.csd.uwm.edu

From: smith@sctc.com (Rick Smith)

>Chuck Moore developed FORTH about 10 years later. I forget just why
>did it, but Kitt's Peak Observatory was an early and ardent user.

Chuck got fed up with the software available to him at the time, so
he developed Forth to do everything he needed to do in the observatory.
Later, Forth became the official programming language for the Astronomical
Union.

>FORTH fits the most hack value in the smallest space of any programming
>language ever developed. No question. If you're severely limited in your
>development environment (sentenced to 8 bit mircos, for example) then
>it's a wonderful choice.

Forth designed based on Chuck's philosophy is inherently small, but
some modern Forth are getting "fat".  

>If you have to deal with big bucks, serious requirement specification,
>source code control, change tracking, ad nauseum, then I don't know
>how well FORTH would work. It really is designed for a *micro* system
>environment (not large, not medium, not mini, not small, but *micro*).

Source code control can be a big problem if the programmer is not extremely
well disciplined.  Forth is designed to fit in a micro system but not for 
micro system.  The original Forth is a multi-tasking and multi-user
system.  There are also distributed and multi-procersor Forth systems.  

>My own rule of thumb:
>If you can't do it in a weekend, maybe you shouldn't do it in FORTH.

If you can't do it with ________ in a weekend, maybe you should do it
in Forth.