Newsgroups: comp.realtime,comp.robotics
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!jfox
From: jfox@netcom.com (Jeff Fox)
Subject: Re: Forth (was Re: Real-time systems:  Windows-NT or QNX)
Message-ID: <jfoxCy4w86.525@netcom.com>
Summary: corrections
Sender: jfox@netcom.com (Jeff Fox)
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <38dl36$ne5@ixnews1.ix.netcom.com>
Date: Sun, 23 Oct 1994 16:24:05 GMT
Lines: 172
Xref: glinda.oz.cs.cmu.edu comp.realtime:7317 comp.robotics:14665

In article <38dl36$ne5@ixnews1.ix.netcom.com> 
             rant@ix.netcom.com (Ran Talbott) writes:
>In <jfoxCy47rs.p7@netcom.com> jfox@netcom.com (Jeff Fox) writes: 
>
>>It offers programmers more freedom than most languages
>
>Depends on how you define "freedom":  I happen to think that
>ready availability of off-the-shelf components for handling 
>common (or even not-so-common) functions very often gives
>me the "freedom" to work on the portions of the system I
>find more interesting.

Well if you have used Forth you know what I am talking about.  You have
been talking about the same thing.  It is both the strength and
the weakness of the language that it allows this "freedom".  You
can redefine anything, create new syntactical structures, etc.
It has no rigid typing, or really rigid anything.  

Not all the same programming practices apply to all languages and
some things that other languages encourage can get you into trouble
fast in Forth.  There is often little compile time checking and
other safety nets in other languages.  This is a very common thread
in Forth discussions.  

Some languages are designed to limit the scope of programmers actions
in an attempt to manage large teams of programmers.  They must not
have complete freedom, they must pull together.  Forth is  most often
used by individuals and small teams, but there have been large projects.
Special care must be taken to keep large groups of programmers pulling
together.  These are the flip sides of the coin.  

I may be a Forth nut, but I try to discuss both the strengths and
weaknesses.  Many Forth programmers chose Forth because they feel the
most freedom there.  Why not admit to that?  It is the responsibility
to do it right that is the flip side of that freedom.   

Most "C" compiles don't come with source code.  So if there are
any bugs you have to work around them.  Forth usually gives you
the freedom to change anything in the compiler if you want.  Freedom
and plenty of rope to hang yourself if you want or don't know
better.

Now some "C" compilers do come with source code.  But I find I can
read and write something with 25k of source more easily than something
like gcc with xx megabytes of source.  You just don't have the
same type of freedom when your source is N times bigger.

"C" is more rigid.  If you make major changes to the language then it 
isn't "C" anymore.  But Forth is designed to "extend" the language and
as such  gives more freedom.  How could anyone deny this?
Let me say it again.  It is both a strength and a weakness, but you 
know it is true.  You seem to regard the negative side of this
freedom as the problem with Forth, while denying that this
freedom exists.

>
>>This is NOT true. Sorry :-) An optimizing Forth compiler can pull
>>all of the same tricks that are used on a given processor to
>>get fast code.
>
>No.  By definition,  it can't,  because the Forth language model of
>using two stacks means that at least one more register has to be
>dedicated to "overhead",  making it unavailable for optimizing
>variable access.  On most micros,  this is a significant performance
>hit.
>

NO. Still not true.  You got it backwards.  If you don't have a 
second stack for passing parameters you must use something else. Some
languages MUST create frames on their return stack and  mix parameters
with return addresses.  So factoring of functions may require
setting a stack frame, copying parameters to this space, then 
restoring the stack properly when the function is done.

If your machine has lots of registers then the compiler can do useful
things with them.  When you run out of them where do you pass parameters?
A second stack can be a simpler and faster way to pass parameters than
some other mechanisms.  This is one reason why some Forth compilers will
produce code that is faster than most (if not all) "C".  

It is very hard to make sweeping generalizations about what is always
the case.  There is every flavor of Forth, and MANY flavors of other
languages.  You might notice that some "C" compilers produce faster
code and smaller code that others, and it is a pretty wide range.
Therefore you just cannot say "Forth will always do this, or C will
always to this."  A lot depends on the implementation.

>> If you don't notice the word "most"
>
>I hear Lenscrafters has stores from coast to coast.  Probably even in
>Alaska and Hawaii...
>
>>you might notice the word "*always*" and think it meant something.
>
>Which,  oddly enough,  it does:  since most implementations of Forth
>are threaded interpreters,  they will always execute more slowly than 
>equivalent native code.
>
>>"Most" means "some don't", so *always* is very misleading.  
>
>Sorry you didn't get it.  I'll try typing more slowly next time.
>

Ok, maybe I'm slow, "most will always" is still there in your
sentance.  That is not the same as "all will always" or "Forth
will always".  

I think people have picked up on the fact that when you say "most"
you saying that there are some to which this statement does not imply.
Sure "most" Forths produce code slower than "C".  I can say many
things about "most" "C" compilers, but I would not say that these
things are all inherant in "C".

>>Forth is generally accepted as the best language for development 
>>where resources are limited and maximum performance from limited
>>resources is desired, and development cost and time are limited.
>
>Not on this planet,  it's not:  as you,  yourself,  have acknowledged,  its
>"reputation" (deserved,  or not) is very different.
>

Sorry, I meant to say that Forth is more suited for this type of application
than for some others.  I did not mean "Forth is the best language" but
rather this is what Forth is best at, compared to other applications
not other languages.  And I certainly would not say that "Forth is
generally regarded as the best language .."  if I was more careful.
We all know how it is generally regarded... :-)

>>What language do you program in Ran?
>
>Depends on what the job requires:  in the last 25 years,  I've written
>in C, Forth, PL/M,  APL,  COBOL,  PL/I,  SNOBOL,  TAL,  FORTRAN,  
>BASIC,  assembler for at least a dozen different CPUs,  and probably a
>few more I've forgotten.
>
>>Has it warped your mind?
>
>Conceivably:  I find I've lost nearly all tolerance for simplistic answers
>over the years.  But that may just be part of growing up...
>

Except your own?  It seems to me that you are giving people
simplistic answers by leaving out one side of the picture.

>>Where was it that you heard this stuff?  Not here.
>
>Oh,  in lunchrooms,  FIG meetings,  the pages of Forth Dimensions.
>Pretty much anyplace the "Forth community" gathers or writes.
>

Well Ran all of these topics have been discussed many times in
those places.  These discussions cover the strengths and
weaknesses.  You seem to have missed half of these discussions!

I have been trying to present both sides of these discussions, the
strengths and weaknesses.  

>> I am sure many people realize that realtime and robotic
>>applications ARE the "very limited" applications where Forth can
>>be very hard to beat. :-)
>
>And I'm sure that many people realize that "realtime" can cover
>anything from a fancy digital watch to Star Wars,  and encompasses
>many applications that are suitable for Forth,  and many that aren't.
>
>Ran

I agree with your last statement completely.  It is very hard to
say "always" and "never" when discussing this  very wide range of
things.

Jeff Fox
