🚀 go-pugleaf

In article <369@chinet.UUCP> magik@chinet.UUCP (Ben Liberman) writes:
>From: jer@peora.UUCP (J. Eric Roskos)
>
>I have wondered whether there might be some demographic property of 
>FORTH enthusiasts that's not immediately apparent -- e.g., maybe they
>run machines without any random-access mass storage device, or with
>very small memory; or maybe they are used to programming in BASIC and
>an assembler language, and then discover FORTH -- but since these
>attributes *aren't* things apparent, it's hard to know.

Is this supposed to be a knock on Forth programmers (BTW, "Forth" is _not_
an acronym, unlike COBOL or BASIC, so should not be spelled with all caps)?
I am not "used to programming" in BASIC and assembler (although I have used
both quite a few times in the past); in fact, before I started programming
in Forth, I primarily used Pascal and C.  For the last two years I have been
a Forth programmer and love it.

>Thus my question... what is the real *advantage* of FORTH?  If you answer,
>please avoid terms like "incremental compilation" and "threaded" unless
>you actually explain an implementation to show why these concepts are
>really beneficial, and what architectural properties of a machine they would
>fit well with.

As I said earlier, I _do_ love Forth.  And it can be highly advantageous in
certain situations.  I was exposed to it through the need to develop a
prototype system for a project at work.  We looked at quite a few products
in trying to choose a language for the prototype (to be implemented on an
IBM PC).  Cs, Pascals, Prologs (the system was to involve some AI techniques),
and Forths.  We chose Forth for several reasons:

	o "Incremental compilation".  There.  I said it.  Just one situation
	  under which this is beneficial (since you asked) -- prototyping.
	  Developing a prototype requires a development environment in which
	  ideas can be represented, implemented, and extended quickly.  The
	  environment also needs to be flexible enough to tailor it to one's
	  own needs.  Forth offers ALL of the above, and no other language can
	  come CLOSE to Forth for doing this.

	o Compactness.  We ended up using Forth for the full-scale system,
	  and the source code turned out to be a little over 1 1/2 meg
	  (which, BTW, we believe is one of the larger if not the largest
	  Forth program ever designed), written virtually entirely in high-level
	  Forth (excluding a small amount of the nucleus and just TWO other code
	  words: one to turn the vertical retrace on, one to turn it off).
	  This whole thing compiled down to 113K and runs in 128K (could be 64K
	  if we trimmed down the amount allocated for the stack segment).  And
	  it's VERY fast.  We calculated that the C code required to produce
	  the same system would have been 3-4 TIMES the size, would have
	  compiled down to perhaps TWICE the size, and run in nowhere NEAR the
	  space.  So you can see (can you? :-) that Forth can be a full-scale
	  development language/environment as well.

I'm not going to go into "threaded" and machine architectures.  I'm a software
guru, not a hardware one, so I'll leave that up to those with more qualifica-
tions in those areas.  (Tom Almy, care to comment? :-)

I will say in closing that my beliefs as an engineer involve fitting a language
to a given problem, not the other way around, so I am not one of those people
who does absolutely EVERYTHING in one language, be it Forth, C, or otherwise.
The reasons listed above are, I feel, some of Forth's primary attractions.  And
I will continue to use it when I feel the situation is appropriate (which is
quite often :-)

-------------------------------------------------------------------------------
Greg (can you say LAYOFF??  There, I knew you could :-) Lacefield
...!tektronix!tekgen!gregl
    ^^^^^^^^^ maybe not for long :-<