Path: utzoo!attcan!uunet!convex!killer!ames!pasteur!ucbvax!decwrl!hplabs!hpl-opus!hpccc!hp-sde!hpfcdc!hpislx!hpmtlx!adam
From: adam@hpmtlx.HP.COM ($Adam Kao)
Newsgroups: comp.lang.forth
Subject: Re: Re: Forth Pre-Compier
Message-ID: <810002@hpmtlx.HP.COM>
Date: 2 Sep 88 14:32:45 GMT
References: <1593@crete.cs.glasgow.ac.uk>
Organization: HP Manufacturing Test Division - Loveland, CO
Lines: 82

Fraser, the reason I like forth is because it's INCREMENTALLY COMPILED.
This means I get the fast turnaround of an interactive system (think-edit-
run vs. think-edit-compile-run) while generating code that runs almost as
fast as compiled code.

The reason I dislike C (or any other compiled language) is you can only use
it if you fully understand the language already.  You can't explore.  For
instance, while learning how to program with the X window system there were
many many times when I really needed to know whether some construct would
work or not.  Sometimes, by the time I finished editing-compiling-running
a program to test my construct, I had forgotton what I was doing before.

Fast interactive systems are essential for fast learning.  Often you want to
put what you're doing aside to examine some part of your code in more detail.
The faster you can do that and come back ('return from the subroutine' :-)
the smoother your overall development process will go.  There are two ways you
can achieve this:  You can buy a ten thousand dollar development system or
you can have an interpreted or incrementally compiled language.

I think this and the other reasons that have already been posted are excellent
justification for rejecting a preprocessor.

There is another point you made which I think deserves answer.  You mentioned
that extensible languages lead to 'Towers of Babel' when many programmers
try to work together on the same project.  This may be the most relevant
thing you've said yet :-).  In fact, I think you should read "Computer
Languages" by Naomi S. Baron, Anchor Press/Doubleday.  Ms. Baron is a linguist,
and her assessment of twenty-two popular and interesting computer languages
is both insightful and fair.  (Needless to say, her assessment of Forth pays
appropriate homage to its unique power :-).

Ms. Baron says, in essence, that non-extensible languages are designed for
programming large systems where many programmers must read each others' code
and most code written is expected to have a useful lifetime of years or even
decades.  The designers of Ada made explicit reference to this principle when
deciding to make Ada non-extensible.

Extensible languages, on the other hand, are designed for rapid prototyping,
usually one programmer with one vision.  In this environment, most programs
don't even exist long enough to be given a name.  That's why Artificial
Intelligence researchers MUST have an extensible language like Lisp or Prolog.

So this is really a question of technology appropriate to the situation.  What
you say about large programming projects is true, but you haven't acknowledged
the OTHER programming philosophy.

I subscribe to the second philosophy.  I am not interested in creating huge
systems where my contribution is relatively minor.  I am not interested in
programming for the Department of Defense.  I view programming as a form of
personal expression, a way to create order and pattern that rivals poetry
in power and insight.

Someone (in this group?) once said, Forth rewards writing skills, Pascal and
C reward outlining skills.

About RPN:  Fraser, living in Europe you should understand this better than
most Americans.  The most effective way to communicate with someone else is
to speak THEIR language, not make them speak yours.  RPN is closer to
the computer's native instruction set, it maintains a strict correspondence
between Word and Instruction(s).  I defy you to produce an infix notation
that can be interpreted at anything lower than the Statement level.  This
really is important - you MUST write a multi-state parser to interpret
infix notation, while RPN words compile themselves.  

Don't think I mean we should all program in assembly language (though I do
think we should all know how).  My point is that Forth provides all the
power of a high-level language while maintaining direct control of the
low level bits.  I know that when I program in C or Lisp I often feel
totally isolated from the hardware - not insulated, ISOLATED.  And often
I NEED to know what's going on in some memory location to fix my bugs.
That's why there are so many debuggers for C and so few for Forth.

These last two points are more eloquently stated in 'Thinking Forth', by
Leo Brodie.  I know this book has been mentioned before, but it bears
repeating (and rereading).  If you want to understand Forth, (and I don't
think you should argue about what you don't understand) you MUST read this
book.  If you've read it already, read it again, more carefully.

I apologize for blasting you, lo these many weeks ago.  I see you've learned
effective use of the :-).  Good. :-)

Adam