The strengths of FORTH

I have followed with considerable interest, the thread 'The Promise of
FORTH' 
started by Johan Thomas.  Much has been made of FORTH's perceived 
shortcomings but as these are mostly inherent, there is little likelihood 
that any significant changes can be made.  That said, I think most here 
would like to see a thriving Forth community.  In order for that to
happen, 
the first thing is to get the existence of the language into the 
consciousness of the general programming community.  John Doty's complaint

that there is no body of shared Forth code reflects that.  The second
thing 
is to identify those strengths of Forth that would make it attractive to 
potential users and somehow getting the word out.

From my point of view, the attractive features of FORTH are; first that it

is an incremental compiler, second that it incorporates an assembler, and 
third it is extensible.   Back at the beginning of personal computers,
Basic 
was the language of choice for hobbyists.  This provided a fairly
immediate 
means of trying new code.  The lengthy and too often repeated sequence of 
edit - compile/assemble - link - download - and test is eliminated.  (If
you 
have ever worked with a paper tape based machine that can be a very
lengthy 
sequence.) This encourages bottom up implementation with testing of the
code 
almost concurrent with its creation.  The result is the next layer is
built 
on (hopefully well) tested code.  In the final analysis this process
results 
in reliable, working code being created quite quickly.  An incremental 
compiler such as FORTH provides the same advantage without the
interpreter's 
overhead.

Having an assembler built into the language is most useful when dealing
with 
hardware but also allows optimizing heavily used or time critical
functions. 
Combined with the incremental compilation, it facilitates the rapid 
development and testing of hardware interface code - which in embedded 
applications is very important.

Although extensibility is not a big issue for my application, it is a 
powerful tool for anyone who needs it.  I have done quite a bit of 
(admittedly boringly linear) work using C/C++ and I haven't encountered 
anything like DOES>.  If you want OOP, it would seem that you could add
it. 
(How about an OOP word set in the next standard?) If you haven't time to
add 
badly needed OOP to your FORTH , use C++ or some other language.

As to the perceived disadvantages of FORTH, the readability and 
maintainability issue can be dealt with by maintaining a bit of discipline

in commenting.  I am certain that anyone here would have no trouble 
following or modifying any of my code even though it was written for a
hobby 
application. (Doubtless my factoring and my studious avoidance of
variables 
would draw hoots of derision from some though.)

As to getting FORTH known to the wider community, I am at somewhat of a 
loss.  Certainly encouraging code sharing would be helpful - if the shared

code was well done and well documented.  Maybe FORTH Inc. should be 
providing T-shirts displaying their Logo with each SwiftX or SwiftForth 
license or with each addition to a shared library - or at least offering 
them for sale.  I go to a gym across the street from QNX and a lot of the 
people in the gym are wearing QNX Ts.  I wonder how many of these guys
have 
ever even heard of Forth.  Every little helps.

In any event, it would be most helpful if c.l.f participants were a bit
less 
negative.



Bob Miller