Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!umich!umeecs!dip.eecs.umich.edu!walden
From: walden@dip.eecs.umich.edu (Eugene Marvin Walden)
Newsgroups: comp.lang.forth
Subject: Re: Language, Operating System, Hardware for Industrial Process Control.
Keywords: Real-time, Forth, DSP, OS
Message-ID: <1990Sep18.154310.28537@zip.eecs.umich.edu>
Date: 18 Sep 90 15:43:10 GMT
References: <1405@umriscc.isc.umr.edu>
Sender: news@zip.eecs.umich.edu
Organization: University of Michigan EECS Dept., Ann Arbor, MI
Lines: 20

In article <1405@umriscc.isc.umr.edu> rajuk@ee.umr.edu (Raju Khubchandani) writes:

<stuff about Forth deleted>

   Make sure you are wary of who you are getting advice from. I am not sure 
why, but it seems that every person I've talked to who claimed he was a Forth
programmer seemed to be romantically involved with the language. I don't think
I ever got an objective opinion from  a Forth programmer-- they all insisted,
with gleaming eyes that, "Forth can do *anything*!!!!!" 
   All sarcasm aside, the feel that I got was that Forth was good for a small,
embedded application. If you are involved in a project that will have many
communicating modules, though, Forth may not be appropriate, because of its
explicit stack-based parameter passing. This can produce errors that are hard
to detect. 
   I'm sure there is a member of the Forth Cult out there who will insist that
Forth is great for everything, but I remain unconvinced.

>Raju

   - Eugene Walden (walden@dip.eecs.umich.edu)