Re: Comment on Ada usage

[Jerry Petrey <"jdpetrey<NOSPAM>"@west.raytheon.com>]

Ted Dennison wrote:
> 
> In article <3B82CD0B.4A551A42@sparc01.ftw.rsc.raytheon.com>, Wes Groleau says...
> >
> >
> >In embedded systems: ADA [sic] is used less than Forth ?
> >http://www.embedded.com/story/OEG20010813S0073
> 
> That was a reader survey. In the article he comes right out and says this isn't
> even close to scientific. He even points out some places where their numbers are
> horribly at odds with more scientific polls.
> 
> I'd be more interested in Jerry Petry's opinion of his charactarization of Forth
> vs. Ada, as he's a fan of both languages (whereas this guy obviously isn't).
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com


I couldn't resist Ted.

I have had two articles published in ESP, one on Forth in 1989 and one
on
Ada in 1995.  After each, when I proposed a follow up article, I was
told by
the editor that they did not want to publish 'too many' articles on
languages
other than C or C++ because they didn't want to 'offend' their readers
and
advertisers - most of whom they considered C and C++ fans.  Jack Ganssle
is one
of their writers who has such a strong bias against both Forth and Ada
(which
he can't even spell correctly).

I used to work for Forth, Inc. which was founded by the inventor of
Forth,
Chuck Moore.  It is still run by the world's second Forth programmer,
Elizabeth
Rather.  I used Forth a lot in the 1980's and designed and taught some
Forth 
classes. I was always impressed by its power and simplicity.  You could
do so 
much with so little memory.  The whole Forth system with compiler,
editor,
assembler, debugger would fit in less than 20K bytes on the target and
you 
could develop and interactively test your application on the target over
a 
serial link from a terminal or PC.  It was especially great for testing
out
new hardware.  You could write quick routines to repeatedly exercise
certain
parts of the hardware so you sync up a scope and really see what was
happening.
At Forth, Inc., we helped FedEX implement their handheld package scanner
in Forth
after they had failed to get it to work using C.  We implemented a
complete airport
control system in the Middle East with some 400 processors all running
Forth.
It is still used a lot more today than people realize (such as in the
boot PROMs of
Sun workstations) but like Ada it is more of a competitive secret and
embedded in
things where you wouldn't be aware of the language used.

When I first started looking at Ada in the late 80's, I was similarly
impressed
with its power and simplicity.  Even though Forth and Ada were vastly
different,
I saw some similarities in the Forth philosophy and the Ada philosophy. 
In Forth,
although it was not enforced by the language, we used a component
programming 
approach where you would define interface words (a word is like a
subprogram)
and implementation words.  You could build an application where the
underlying
implementation could be changed (faster algorithm or even re-coded in
Forth's
in-line assembler) and the users would not be affected as long as they
adhered
to the interface.  By proper choice of names of words, Forth could even
be made
quite readable - in spite of its popular criticism to the contrary). 
For
example, the top level application for a washing machine control might
be:

: Washing_Machine   Wash Delay_1 Rinse Delay_2 Spin Delay_3 Stop ;

The : starts a definition (and the incremental compiler) and the ; ends
it.  
The first word is the name of the procedure and the remaining words are 
lower level words previously defined.  These words would control the 
actual hardware - motors, relays, timers, etc.

Forth is very useful for smaller microprocessors with limited resources
such as older RAD hardened processors used in space and military
applications.
 
Ada is my choice for large applications.  I wish it was available on
smaller
8-bit processors as well but I'm certainly glad that Forth almost always
is.


Jerry
-- 
-----------------------------------------------------------------------------
-- Jerry Petrey                                                
-- Senior Principal Systems Engineer - Navigation, Guidance, & Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to
reply                  
-----------------------------------------------------------------------------