FORTH, the heat is on (sorry Don Henley) [long]

[Peter da Silva]

> Onwards.  (2) is certainly true of Forth, and certainly not true of languages
> like C or Pascal, unless someone is really determined.  However, it appears
> to be a standard technique in Forth to write modifiable code.  It certainly
> is easy to do--much, much easier than in C or Pascal.  I have seen enough
> examples of such coding (by competent Forth programmers) to convince me
> that such practices are status quo in the Forth community.

I'm a competant FORTH programmer. I have written a *LOT* of programs in FORTH,
including two special-purpose compilers, a screen editor and a display generat-
or, and untold numbers of utilities. I have never used self-modifying code.

> Now, then. (3) is most certainly not a subjective judgement; it is the core
> of the Forth philosophy.  If you do not understand this, then you lack a
> basic understanding of how Forth works.  I would be most curious to see
> an example of a Forth program (of modest size) which did not define any
> new "words" in order to perform a useful task.

I would be happy to post such a program to the net (by new words I assume you
mean new control- and data- structures, not just subroutines), but I am not
at liberty to do so (trade secrets, copyrights, and other unfunny things
stand in the way).

> >>1. Forth is a lot harder to read than even Lisp or APL; at my former employer,
...
> 
> This is certainly true; however, the tendency to write unreadable code is
> accentuated in Forth because the language itself provides no help whatsoever
> to aid the programmer in writing clean code.

This is not really true. A better way of putting it would be that the author
of FORTH, Chuck Moore, writes horrible code... and this has diffused down into
the FORTH community as a whole. WARNING: DO NOT USE FORTH FOR YOUR FIRST
LANGUAGE. Learn to *program* first. And if at all possible throw screen files
out the window & use regular text files (the UNIX FORTH I posted to the net a
while ago does this).

> >>2. There are many incompatible implementations of Forth, and even
> >>implementations from the same vendor behave radically different on
> >>different processors.

True. Except that FIG-FORTH is extremely portable (having ported a screen
editor between FIG forths in the Apple-][+, CP/M, RSX, and RTE-IVB (HP1000)).
Careful non-use of "find", "-find", "?find", and other obscenities can
ameliorate this problem considerably. Avoiding assembly language helps a lot
too.

> >>3. The debugging support is non-existent.

That depends. The support for code development is extremely good (how many
languages have interactive source-level debuggers built in?). After that,
though, you have to fall back on lots of dot-quotes and cross your fingers.

> You, my lucky friend, are working with a Forth onto which someone has
> added some semantic sugar.  However, possession of a do-loop, a couple
> of conditionals, and an iterative structure does not make Forth a
> structured language.

A language in which GOTOS are virtually impossible "unstructured"? Sorry,
cheap shot. At least FORTH is more structured than the alternative: assembly.
In an application where FORTH is used you generally don't have the option
of using another "high" level language.

> >>> 3) Forward referencing (including recursion) is not normal and must be
> >>> done by manipulating compiled code.  Bye-bye portability. Indeed, I have
> >>> never seen anyone write a recursive Forth routine (although it can be
> >>> done).  Bye-bye AI. 

: recursive-routine
  blah blah blah
  [ smudge ] recursive-routine [ smudge ] ( bletch. horrible syntax )
  blah blah blah ;

> >>> optimization, etc.  As for syntax checking, forget it.  The syntax of
> >>> the language is so simple, almost every combination of Forth words is
> >>> syntactly correct (although meaningless).  If you mistyped that last
> >>> word, you'll find out at run-time. 

Only in Chuck "syntax checking? that's inefficient!" Moore's implementation.

> >>> 5) Scoping, name-space rules are terrible.  For example, it is impossible to
> >>> write a subroutine that uses variables that are *guaranteed* to be local.
> >>> (How can you ever be confident about your code?) 

vocabulary barvoc immediate

barvoc definitions
0 variable var1 ( ... )
forth definitions

: bar
  barvoc
  blah blah blah var1 blah blah blah ;

> Uh-huh.  Note that subsequent function definitions would, however, use the
> new operator "+".  Note also that scoping is built in to most languages,
> so that kludging it in isn't required.

See above definition.

> Nonsense.  Using a variable in Forth results in slow execution, and yields
> ugly code, since Forth abhors non-stack parameters.  The use of threaded
> code has next-to-zero influence on the edit-compile-test cycle; as most
> folks familiar with software engineering know, there are a couple of blocks
> in there marked "think" that represent the largest expenditure of time.
> Forth does nothing to reduce the time spent there.

No, but reducing the time spent compiling code (and arguing about the latest
language at the desk instead of on usenet) is an admirable goal.

> ----------
> To borrow from some anonymous person on the net from a while back,
> Forth is like falling in a hole, crawling out after a protracted
> struggle, and then saying "Look at the great thing I've done."
> I don't think anyone should take this language seriously; it's just
> too hard to learn, too hard to use, and too antiquated.
> -- 

If you have anothe alternative, by all means use it. Most of the time the
only alternative to FORTH is assembly language because of memory constraints
and/or the lack of a good host system. In that case, go FORTH and prosper.
-- 
-- Peter da Silva
-- UUCP: ...!shell!{baylor,graffiti}!peter; MCI: PDASILVA; CIS: 70216,1076