Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mailrus!caen.engin.umich.edu!stejk
From: stejk@caen.engin.umich.edu (Steven J Kassarjian)
Newsgroups: comp.lang.forth
Subject: Re: Forth "Pre-Compiler"
Summary: history
Message-ID: <3d7612e1.13370@dow4.engin.umich.edu>
Date: 25 Jul 88 13:56:00 GMT
References: <8807221513.AA05347@jade.berkeley.edu>
Organization: U of M Engineering, Ann Arbor, Mich.
Lines: 43

In article <8807221513.AA05347@jade.berkeley.edu>, DAVID@PENNDRLS.BITNET writes:
> Someone whose name I have lost wrote:
> 
> >Why I LOVE Forth:
> >
> >       It is FAST! -- Above all else, Forth is one of the fastest
> >       executing languages around.  Since it is functionally both a
> >       compiler and an interpreter, this speed is evident both in the
> >       execution of the program and in it's compilation.  The speed of
> >       Forth also makes for rapid prototyping.
> >
> 
> The claim that FORTH is one of the fastest executing languages around
> makes me think the author has used only interpreters previously.  By
> its very nature FORTH programs *must* be slower than programs generated
> by a good optimizing compiler.  The gap can be closed (in some cases
> to almost nil) by coding hot loops in assembler and by using a direct
> threading FORTH, but overall FORTH *must* still be slower.  Of course,
> if you take the time to learn good FORTH coding techniques your programs
> (both in FORTH and elsewhere) will tend to get more efficient :-).
> 
   Looking back into history (watchout- I'm "young" and could be wrong;  or
even worse, partially wrong), it seems that 'optimizing' compilers have not
been in existance for long.  Thus, because of its simplicity, Forth was (much) 
more optimized than a "Traditional" compiler.
   Second, as David suggests, hot loops coded in assembler.
   The key though, is the rapid prototyping, I believe.  Through rapid
prototyping, information hiding (data and algorithm), several algorithms may
be tested, and the best one determined _empirically_.  Traditional
languages (then) could not possibly support the interactivity that makes such
quick changes (and testing) possible.
   Much of this is changed now, with the very quick compilers and optimizing
compilers (though they seem to be exclusive).  Forth is still fast and has
room for growth, such as the support the 68000 can offer (hardware stacks,
(I think), and such), or even Forth in hardware (Novix, Rockwell).

   Personal Experience.  As much as I've used Fortran (I'm a ChE), I doubt I
ever will _think_ in Fortran.  For the short period of time I used Forth
(one class project), I started to think (and dream) in Forth.  (I was under
a lot of pressure, too!)  (strange  :-)

(is my signature working?)
steve kassarjian  as  stejk@caen.engin.umich.edu