Path: utzoo!utgpu!attcan!uunet!husc6!rutgers!ucsd!ucbvax!SCFVM.BITNET!ZMLEB
From: ZMLEB@SCFVM.BITNET (Lee Brotzman)
Newsgroups: comp.lang.forth
Subject: Re: Forth "Pre-Compiler" (long)
Message-ID: <8808032106.AA01436@jade.berkeley.edu>
Date: 3 Aug 88 19:15:31 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 91


In article <810001@hpmtlx.HP.COM>, hpl-opus!hpccc!hp-sde!hpfcdc!hpislx!hpmtlx!
adam@hplabs.hp.com  ($Adam Kao), writes:

>Mr. Orr, did you know the net gods, in their infinite wisdom, have created
>an entire newsgroup just for your kind of writing?
>
>It's called alt.flame.
>
>I suggest you go there and don't come back until you can be polite.
>
>Adam

   Let me answer with an old American saying: "I may not agree with what you
say, but I will defend to the death your right to say it."  If only it were
more than just a saying, eh?

   I think Mr. Orr's comments could have perhaps done with a few sprinkled
:-) and ;-) here and there, but I don't take his criticism of Forth as simply
flames.  I have written a few public domain and commercial Forth development
systems and am definitely a fan of the language, but I also agree with
Mr. Orr's observations that program design should concentrate on the problem
not the answer.  I tend to disagree, however, when he asserts that Forth
distracts from thinking about the problem.  By the time one is ready to write
code, the problem had better be solved already, otherwise, no language
is going to help.  That's what the modern software design methods teach us,
anyway.

   As for program readability, I can take any language and make it completely
unintelligible, what does that prove?  To argue whether it is easier to
write unreadable code in one language or another is silly.  The point to
make is that code should be readable, period.  Mr. Orr has admitted that he
hasn't used Forth for some time.  That's no crime, but perhaps his attitude
would soften a little bit if he were introduced to the more recent advances
in the language's constructs (by recent I mean in the last five years).

   Use of multiple-code-field named variables reduces or eliminates the need
for the @ and ! operations by imbedding them into the word itself.  A variable
is defined like before, except with an initial value: "0 VAR TEST".  When
TEST is executed, it pushes its *value* on the stack, like a constant.  To
store a new value in TEST one can say: "10 TO TEST".  To get the address of
TEST, one can say "AT TEST".  The use of English verbs to describe the actions
enhances readability, and the implementation of these words has actually
proven to be faster than the traditional @ and ! way of doing things.

   Several Forths have implemented full data structure defining words which
are analogous to C's struct and Pascal's RECORD.  The syntax is clean and
as readable as either of the other langauges.

   There are also "local variables", which assign names to input stack items
at compile time.  These can be used in lieu of the "DROP SWAP FLOP PLOP"
stack thrashing phenomena.  This does wonders to improve the readability
of the code.  Here, too, execution speed has been shown to be improved
especially in those words which do a lot of stack thrashing.

    Use of structures which vector the run-time definition of a Forth word
like the DOER/MAKE facility outlined in Brodie's Thinking Forth, can greatly
enhance the readability and run-time efficiency of code that must change
with time.  By this I mean that a Forth word can be defined to perform
one action under a certain condition and another action under some other
condition.  It helps to reduce coding messy IF-ELSE-THEN-type statements,
and saves processor time that would otherwise be spent checking
conditionals and performing branches.

   Perhaps the area where Forth has lagged behind other programming langauges
such as C is in development tools: debuggers, context sensitive editors, etc.
Things have improved on this front as well, although Forth is still behind.

   (One could argue that if C is so much easier to use than Forth, why have
C programmers spent years writing development tools, while Forth programmers
seem to get along just fine with only an editor -- could it be that Forth is
so easy to test and debug that no expensive development aids are necessary?
On top of this, the Forth compiler, i.e. the outer interpreter, can be
modified to one's own needs, so the compiler itself becomes the most important
development tool, ala the "integrated environment" so many other compiler
vendors are promoting of late.)

   I have only given a glossy -- and fuzzy -- overview of some of the
things that help make Forth easier to use and more powerful to code in.
I am not saying that Forth is a be-all and end-all; so far, I have yet
to find a programming language that is.  I just want to see it get a
fair shake, and not be judged solely on its past.  By its very nature,
Forth is a constantly and rapidly evolving beast.  It can be extremely
advanced and complex, or incredibly simple and small.  How can anyone
pin a single label on it?

-- Lee Brotzman  (FIGI-L Moderator)
-- My opinions are my own and not those of my employer, ST Systems Corp.,
-- or their employer, NASA Goddard Space Flight Center, or their employer,
-- Ronald Reagan, or his employer, Nancy Reagan, or her employer, the
-- planets and stars.