Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site h-sc1.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!pyramid!ut-sally!seismo!harvard!h-sc1!breuel
From: breuel@h-sc1.UUCP (thomas breuel)
Newsgroups: net.lang.forth
Subject: Re: FORTH, PASCAL, and C--- which one would you choose (it depends ?)
Message-ID: <860@h-sc1.UUCP>
Date: Fri, 3-Jan-86 03:29:08 EST
Article-I.D.: h-sc1.860
Posted: Fri Jan  3 03:29:08 1986
Date-Received: Sat, 4-Jan-86 05:44:44 EST
References: <1191@princeton.UUCP> <681@pucc-j>
Distribution: net
Organization: Harvard Univ. Science Center
Lines: 62

I am not a great friend of FORTH either, but I do not believe that your
criticism is justified.

> 1. Forth is a lot harder to read than even Lisp or APL; at my former employer,
> where we used Forth in real-time control and number-crunching applications,
> we called it a "write-only" language.

I would argue that that is a question of programming style and of
programmer experience. Looking at hacks like the 4.3BSD kernel
or readnews, I can assure you that unreadability and bad style aren't
restricted to FORTH. The cpp, for example, lets you do some pretty
obscure things, and people are doing them...

Also, in your posting, you refer to 'reading from the beginning of
a FORTH definition' or to 'not knowing what is on the stack on the
23rd line'. If you mean this, it simply shows that your problems
with programming in FORTH probably come from bad programming style.
FORTH functions shouldn't be long. If they are longer than,
say, two or three lines, or contain nested loops and if's, you
are probably doing something wrong.

> 2. There are many incompatible implementations of Forth, and even
> 3. The debugging support is non-existent.
> 4. The primitive set of operators is *very* large; and it is not orthogonally
> 5. Forth is not structured, typed, or anything like that.  When
> > impractical, since it has no garbage collection.  You can't expect to
> > 2) Can't pass arguments explicitly.  You must pass information by
> > 3) Forward referencing (including recursion) is not normal and must be
> > 4) Code is generated as you type (or load) in Forth source.  Hence you
> > 5) Scoping, name-space rules are terrible.  For example, it is impossible to

There are implementations of FORTH which provide excellent debugging
facilities and will allow you to track down whatever problems you
are having with your stack. Other implementations allow object oriented
programming. Still others have named local variables or named parameters.
There are native code compilers and optimising native code compilers.
There are FORTH interpreters with garbage collectors, with floating
point numbers, with extensions for 3D graphics or matrix operations.
If you want to, you can define your own abstract operator for defining
forward references. FORTH is, by the way, of course structured in
any sense of the word (or if it isn't yet, you can make it that way :-).
And you can call your operators whatever you like to, if the existing
names trouble you. Since this is relatively easy to do in any implementation,
you don't even necessarily loose portability.

Because there is a bewildering number of FORTH systems, any two
randomly chosen ones are likely to be incompatible. Your conclusion
that therefore FORTH programs must be unportable is simply fallacious,
however. If you pick your implementations carefully (or write them
yourself -- it only takes a few days), you can have as much portability
as with, say, 'C'.

ALTOGETHER,
I personally don't like FORTH and prefer a decent LISP or 'C' compiler
to it for any purpose. This is purely a matter of taste, however. 
You have not cited a single reason that makes FORTH (I would say, not even
any of the standard FORTH's) unsuitable for any particular purpose.
Advice like 'stay away from FORTH and use assembly language instead' is
simply unfounded and inadequate. In particular, there isn't much point
in posting it to net.lang.forth.

						Thomas.