🚀 go-pugleaf

Jeff Fox (Fox@UltraTechnology.com) wrote:
: We have advice here from a couple of people who
: dropped out of using Forth twenty years ago. Their
: opinions are based on comparing twenty year old
: Forths (the last they remember) to the C that they
: use today.

Actually, I programmed in C before I programmed in FORTH. I first learned
C in 1979 out of Kernighan and Ritchie's book.  Years later I learned 
FORTH out of Leo Brodie's book (circa 1988).

Opinions are fine, but facts speak for themselves. Today the C language
has been augmented by the addition of features that at its introduction
were viewed as application/system dependent (since originally C did't
not include any I/O functions. (Most portable C applications still do 
not include them, as they are either not required or supplied by the 
application environment.) ANSI C polished the apply a bit, but didn't
add any utility not originally there.  This is arguably why C has taken
over as the major system implementation language in use throughout the
world through today.  (Indeed, C forms the basis of many application 
oriented supersets including C++ and many others in use today.) 

By contrast, FORTH hit its peak of popularity during the middle to 
late 1980's, and has been heard very little of since. It's probably
realistic to say that it went the way of PASCAL and, while of interest
to some academics and speicialized legacy users (radio astronomy), it's
probably accurate to describe the state of FORTH today as an 
anachronism found only in use for a few niche applications. Due to
the difficulty of maintaining a FORTH program of any significant
size over an extended period of time, FORTH is generally not considered
a viable candidate for any new systems by government and industry 
alike.

Still, if you develop sufficient skill in FORTH, you can likely earn
very good money in doing maintenance and enhancement of legacy FORTH
implementations, just as I am often able to do with PLM. It's simply
that while assignments like these pay very well, they're few and 
far between.  Same thing only better if you have a working knowledge
of (ugh) COBOL -- at least until the Y2K thing ran its course.

Still, let's not make it into another R-Wars issue.  Live and let
live, so if you have the desire to write a 2-5,000 instruction real-time
system application in FORTH, go for it. I prefer to write it in C
(with a sprinking of assembler), but that's simply because while I
like to eat, I don't like the feel of thumb-screws being tightened
on me when the project is over-budget, 2-months late, and the code
reviewers are complaining that they can't understand what the code
does!  ;-)

: To be fair one should compare today's commerical
: Forths to today's commercial C or today's public
: domain Forths to today's C.

What's the point, since it's still FORTH?  Why work twice as
hard for twice as long to turn out a software product that if 
coded in C would deliver equivalent or superior performance at
a fraction of the cost and effort?

For example, try writing a FORTH routine to accept a data stream
from an external input, parse and process it, and program it into
a Flash Memory chip.  The data stream is reaching you in ARINC 429
message protocol, and after processing the data, you're going to 
program it onto an AMD 29F010B Flash Memory.  You're going to need
a data structure to accept and process the incoming data, and you
have to send the control commands and byte oriented data to the
chip in under 50-micro-seconds or the chip times out. You also have
to monitor status bits on the chip to determine when the byte 
programming is completed, before sending it the next byte (roughly
9-micro-seconds).

Couple this with the fact that you have to service a NMI interrupt
every 2.5-MS (you can't turn it off), without corrupting the 
data reception or chip programming operation.

Now seriously, would you chose C or FORTH to implement a system 
function of this type?  No, I didn't make up the above real world
example. It's typical of what most system programmers deal with,
even those at Microsoft.  ;-) 

                                           Harry C.