Newsgroups: comp.realtime,comp.robotics
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!news.alpha.net!uwm.edu!math.ohio-state.edu!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: <jfoxCy47rs.p7@netcom.com>
Summary: Forth is more than this 
Sender: jfox@netcom.com (Jeff Fox)
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <38cbbk$739@ixnews1.ix.netcom.com>
Date: Sun, 23 Oct 1994 07:35:52 GMT
Lines: 104
Xref: glinda.oz.cs.cmu.edu comp.realtime:7314 comp.robotics:14658

In article <38cbbk$739@ixnews1.ix.netcom.com> 
            rant@ix.netcom.com (Ran Talbott) writes:
>In <38b4u5$isa@ixnews1.ix.netcom.com>
            kmgibbs@ix.netcom.com (Kent Gibbs) writes: 
>
>>	Forgive me for my ignorance as I'm not that familiar with
>>Forth, but it does seem to solve some problems in that you are able
>>to build the dictionary to suit the application.  Is this correct?
>
>Yes.  It's also correct that Forth *causes* problems sometimes 
>because you are able to build the dictionary to suit the personal
>quirks of the programmer.  Which may or may not happen to match
>the personal quirks of the guy who comes along a few years later to
>maintain it.
>

This is quite true.  It is part of Forth's bad reputation.  It only
takes a few programmers who abuse the language to give it a 
reputation.  It offers programmers more freedom than most
languages, and as such can really let someone screw things up. :-)
No one could deny that.  (bad code happens... you can quote me)

>>I don't know if it will handle critical interrupts or not
>
>Well,  if you throw enough horsepower at the problem,  you can
>handle "critical interrupts" in interpreted LISP...
>
>>but it does seem to be fast and robust. 
>
>Compared to what?  BASIC?  Sure.  C?  No.  The very structure of
>most Forth systems means that they're *always* going to have a 
>significant run-time overhead.  Which is acceptable in some cases,
>and intolerable in others.

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.  In fact "C" introduces some overhead that can be
avoided by a Forth compiler.  Forth is know as a threaded language,
and when threaded WILL introduce an overhead, but it can be very
small.  (I won't go into how small)  But if the Forth compiles
native machine code, and uses optimizations it can produce code
that is optimally fast. 

>
>>I guess I don't understand the bad reputation.
>

Well, here is an  example of someone saying "The very structure of
most Forth systems means that they're *always* going to have a
^^^^
signifigant run-time overhead."  If you don't notice the word "most"
you might notice the word "*always*" and think it meant something.
"Most" means "some don't", so *always* is very misleading.  But
people base opinions of Forth on what they hear.

>It's very simple:  Forth is the software equivalent of a wirewrap gun.
>There are certain problems for which it's,  not just an acceptable tool,
>but the best one.  But that's a fairly limited class,  and the insistence
>of a vocal minority of "Forth nuts" that it's the be-all and end-all of
>HLLs,  coupled with other unrealistic claims,  has convinced a lot of 
>people that there's something about Forth programming that warps 
>the mind of the programmer ;-)
>
>(Ada was greeted with much the same sort of skepticism,  but we
>*expect* gummint people to come up with wacky,  unworkable
>ideas,  and make grandiose claims for them...)
>
>Ran

You can think of Forth as a software wirewrap gun if you like.  And I
would agree that it is sometimes  the best tool, and sometimes NOT
acceptable for many reasons.  

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.

It is sometimes said that Forth attracts programmers who like small
efficient simple programs.  I think many Forth programmers feel that
it is very difficult to do that with other languages, and that
this is not important to programmers in other languages.

Sure there are Forth Nuts!  But it doesn't mean that people should
dismiss all of the ideas that may be useful.

I think my mind was warped long before I learned Forth. :-)  So in
my case it wasn't Forth that warped my mind.

I would just like to point out that I am posting to "comp.realtime"
and "comp.robotics".  Sure I am a Forth nut, but I have not said
Forth is the "be-all" "end-all" or should be used everywhere or
anything like that.  And I have not not seen anyone else saying
anything like that in comp.robotics.

What language do you program in Ran?  Has it warped your mind?
Where was it that you heard this stuff?  Not here.

Now as to whether Forth has a place in comp.realtime or comp.robotics
get real....  I am sure many people realize that realtime and robotic
applications ARE the "very limited" applications where Forth can
be very hard to beat. :-)

Jeff Fox
Ultra Technology 
