🚀 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 :-<

In article <173@tekgen.UUCP> gregl@tekgen.UUCP (Greg Lacefield) writes:
>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.
>

Currently I run Forth on an IBM PC AT with a hard disk.  In the past I
used a 68000 based workstation and a VAX.  Prior programming experience
include (in chronological order) Fortran, IBM 360 Assembler, BCPL (predecessor
to C), LISP, PDP 11 Assembler, BASIC, Pascal, C, STOIC (related to Forth), 
Forth, Logo, and Smalltalk.  Most of my programming is in Forth.
>
>>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.
>
>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? :-)
>

Basically, threaded code refers to a technique where the function definitions
consist of pointers to other definitions rather than machine code itself.
This allows fast compilation, compact code, but some performance loss.  This
technique was used by PDP-11 Fortran, and by most (if not all) interactive
languages such as LISP and Smalltalk, also UCSD Pascal.

Tom Almy

Once upon a time I was using a machine with limited resources - it
did, however, have a floppy drive and 6k of ROM space.  Into that
space, using a variant of FORTH I was able to put a programming
environment and a disk-based text editor.

Not much, perhaps, but enough to get the Christmas letters out on time
one year, with variations to each recipient.  This justified (for that
year, at least) the expenditures that went into that system.

What impresses me more are the FORTH-based (or FORTH-like) systems
that implement things undreamed-of only a few years ago, things that
you can hold in your hand and run from batteries . . .