Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!att!cbnewse!cwpjr
From: cwpjr@cbnewse.att.com (clyde.w.jr.phillips)
Newsgroups: comp.lang.forth
Subject: Re: What's WRONG with Forth?
Summary: Good good good!
Message-ID: <1991Jan2.193740.13660@cbnewse.att.com>
Date: 2 Jan 91 19:37:40 GMT
References: <2189.UUL1.3#5129@willett.pgh.pa.us>
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 55

In article <2189.UUL1.3#5129@willett.pgh.pa.us>, ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:

I deleted till here...
> sophistication of my tasks increase, I would loose my enthusiasm while trying
> to figure out where in the hell an unexpected stack parameter causes things to
> bomb.

I'm glad you are not swayed by the burnout. This is simply the classic case
of a "motorhead", ie unsafe at any speed. You don't end up in this situation
in FORTH unless you put yourself there, as you state below...
> 
> I don't dispute forth requires certain attention to detail, but from what I've
> seen so far, it's not insurmountable. At work, on multi programmer jobs, we
> all do unit module testing of any code we write or modify. This includes,
> among other things, testing every possible branch of code. This is nothing
> new. What I find refreshing is that forth allows one to far more easily
> perform testing of a module (word) in isolation. Given proper design and
> documentation, I've had no problem yet with the stack containing unexpected or
> no data/parameters.

Yes FORTH is an amplifier. Good techniques really shine!
> 
> The biggest problem I see with forth being accepted in a large way in industry
> is:
> 
>    1. lack of familiarity with forth from computer science and engineering
>       software professionals
>    2. lack of ANSI standard for forth (soon to be reolved)
>    3. a reputation of being unmaintainable and encryptic
>    4. not easily interfacing to commercial libraries of graphics, etc.
> 
> 
> I am making these remarks because I am viewing forth as more of a general
> purpose language. 'C' language, for example, has literally thousands of
> library routines comercially available (some of dubvious quality too).
> 
I like your list, and if we include proper scoping of the Vendors implementation
TO THE APPLICATION we leave little left but good techniques and mgmt to get
the "benefits" of FORTH.

> vehicle simulation on a PC with digital and analog boards to exercise our
> prototype systems. This simulation is done in HS forth.  This is our (my
> company and myself) first serious application in forth.
>a
I've been curious about HS FORTH. I've used a FORTH that allows one to use
"c" data structures. But I've always felt that the better "c" libraries
were a cheap (sometimes) and dirty ( usually ) way to get a bunch of
related "words" with which to rapid prototype an app. This vocabualry
will either prove itself well factored and useful or it will point up
it's deficiencies.

Any comments on this or how seemingly tyour simulator ( with special I/O )
seems especially suited to FORTH would be welcome.

Thanks, Clyde