Re: ada and robots

["John G. Volan" <johnvolan@sprintmail.com>]

Joe Gwinn wrote:

> Experience with Ada83 shows that it is very bad at direct control of
> hardware, especially I/O hardware, and simply does not handle shared
> memory correctly.  

Could you please elaborate a bit on the technical merits of this claim? 
Your assertion is a curious one, because in my experience Ada83 was very
useful for just this sort of application, when applied with a bit of
care and good judgment.  Before anyone on this group can evaluate the
validity of your claim, we have to discount the possibility that your
bad experiences might have been due to (1) the admittedly poor quality
some early Ada83 implementations (happily now _ancient_ history); (2)
poor understanding of the facilities of Ada83, and how best to apply
them; (3) willful _misunderstanding_ of the facilities of Ada83,
attempting to apply them as if programming in a different language,
thereby losing all the advantages of Ada and creating an artificial set
of "disadvantages"; (4) forced introduction of Ada83 into a culture
openly hostile to its adoption, making its failure in that culture a
foregone conclusion; or (5) all of the above.

> Ada95 is claimed to be better, but I don't have any
> direct experience with it.  

Hmm ... so what you're saying is you don't really have any useful recent
information for us, either way?  

>Actually, not many people do just yet.

Oh, there are a few.  I've done my share of low-level bit-twiddling with
Ada95, and before that, with Ada83. I've been getting away from the
low-level stuff lately, but I know of some other folks with some real
heavy-metal experience with Ada95.  Jim H., care to chime in here? :-)

However, in my experience, it's always been the _abstractions_ that have
saved my butt: Because of the (admittedly cultural) tendency in Ada to
encapsulate lower-level stuff into higher-level abstractions, when push
came to shove on efficiency you could go down into the abstractions,
pick a different implementation, and magically improve performance
across the board, without having to do a lot of massive ripping and
tearing in the application design.  But that takes a certain kind of
engineering skill sadly lacking in the typical silicon jockey weened on
C...

> I
> suspect that most people are using C (perhaps called from Ada) for direct
> control of I/O hardware and the like.

Most likely for cultural, rather than technical reasons.

> Most "Ada systems" I have seen built recently are actually mixed-language
> systems, being a mix of C, C++, and Ada, with the Ada being in the
> minority (maybe 25%), if one counts all the purchased COTS code in the
> system.  Typically, the operating system, middleware, and GUI stuff are
> all in C, and the application code is mostly in Ada (with C bindings, and
> no Ada runtime).

It's really a question of attitude: Is your glass 3/4 empty, or 1/4
full?

To me, given the sheer cultural and marketing inertia propping up C, a
25% inroad of Ada on a project sounds like a phenomenal success against
enormous odds. It demonstrates what many have been saying: Ada is great
for gluing together multi-language code, and for adding a much-needed
layer of abstraction over the miserable bit-twiddling that passes for
APIs these days. It also shows that Ada is a good choice for the code
that you actually have to write and maintain yourself (as opposed to the
code you simply buy from somewhere else).

> Not all Ada compilers offer adequate support for such mixed-language
> systems, especially when it comes time to debug on target (vice host)
> systems.  This can be a severe problem, because it's generally impossible
> to build a competitive offering without extensive use of COTS components,
> which are almost always in C/C++, and impossible to get working soon
> enough to matter without good debugging support.  

If the COTS products you bought are so poorly engineered and documented
that you need to diddle them with a debugger (of all things) to get them
to work, or even just to figure out how to actually interface with them,
then you've got some very serious problems that have nothing to do with
the quality of your Ada compiler. The fact that such products are
written in C or C++ is not exactly a glowing endorsement of either of
those two languages.

> Whatever set of
> compilers and tools you plan to use should be demonstrated to do *exactly*
> what you need done, with sufficient performance, before purchase.  Don't
> assume that anything works until proven.  (A year ago, we very nearly
> bought an Ada that couldn't even link a mixed-language (C and Ada83)
> VxWorks system, let alone execute the code and debug.  Insisting on a true
> and accurate demo saved our butts.)

That was, of course, wise.  But I wonder if the same stringent criteria
have ever been applied to those wonderful COTS products about which I've
heard so much glowing hype^H^H^H^H praise lately... :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------