Re: ada and robots

[gwinn@res.ray.com (Joe Gwinn)]

In article <33961528.2A9A@sprintmail.com>, johnvolan@sprintmail.com wrote:

> 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.

OK.  Even if you choose to discount my experience as the blatherings of an
idiot.  But remember, I don't have to convince you of anything.  I do have
to deliver a working, reliable product.

Typically, there are only a few code development systems adequate to the
scale of our developments, and toolset quality is a major productivity and
therefore cost and schedule issue.  This is true of all languages, and Ada
is no exception.  Ada toolsets have always been a problem, due largely to
the small size of the Ada market relative to the C/C++ market. 
Engineering energy follows the money, and money follows market share.  It
doesn't matter at all if one language is better than another, the market
governs, right or wrong.

As for Ada83 experience, I have (or know of) both old and new experience,
and most Ada83 compilers were very difficult to use for direct hardware
control.  I suppose one could have made them work, but why would you?  If
it's that hard, it won't be reliable.  We often reverted to assembly code
for the machine control bits, long before C was a true option.  (We did
the same when the base language was Fortran or Pascal, for the same
reasons.)  

The shining exception to Ada83-can't-do-hardware was the late lamented SD
Ada, and some people had success with pre-Rational Verdix.  I think it
depended on which target system was chosen.  

As for Ada83 and shared memory, the problem was that the Ada83 compilers
all believed that only they changed memory, so it was OK to cache data
items in CPU registers for long periods of time.  For the most part, there
was no reliable (and portable) way to tell the compiler different, so we
performed various dances to ensure that Ada83 never knew the whole truth.

In the current development, the one with 25% Ada and the rest C/C++,
mentioned below, which is being coded as we speak, Ada talks only to
VxWorks (via a binding), and only the C-coded I/O drivers touch metal. 
This was decided on architectural grounds, not language issues: the rule
is that application code (regardless of language) is forbidden to touch
metal.  Confining hardware details to these I/O drivers makes the overall
system more portable and resistant to inevitable hardware changes.

I must say that our greatest problem with "willful _misunderstanding_ of
the facilities of Ada83" have been in the direction of incautious overuse
of some inappropriate features of Ada.  Just because a language has a
feature doesn't mean that the feature should be used in a specific
application.  This is true in all languages, and all teams have their
incautious members.

The team is a mixture of Ada lovers (including the chief programmer, who
loves SD Ada), C++ lovers (used for the GUIs), cynical agnostics (such as
myself), and programmers without portfolio.  


> > 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?  

That is what I said, only more politely.  What's the point you wish to make?  

Anyway, on Ada95, not yet.  We are just now benchmarking the Ada83 code in
which the project will be coded against both Ada83 and Ada95 compilers. 
For portability and from fear of the immature, we are staying in the Ada83
subset of Ada95.  


> >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? :-)

Just as I said: "not many" is the same as "a few".  As I said above, we
are in the process of trying an Ada95 compiler.  However, we will not test
the ability of Ada95 to do direct machine control, although one would hope
and pray that it is improved over Ada83.



> 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...

Abstractions are language independent.  So is programmer skill.

 
> > 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.

No.  It's lazyness: cost and schedule.  Current COTS operating systems are
in C, as are I/O drivers for those operating systems.  We can get the code
and reuse it.  Using Ada to write an I/O driver for a C-coded operating
system doesn't seem like the shortest road home to me, especially if a
driver is already available.  Driver writing is difficult, and best
avoided.

 
> > 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).

Use of Ada was mandated by our DoD customer.  Actually, they now regret
it, but it's too late to change.  And, Ada isn't gluing anything together,
it's being glued together with C.  None of the APIs know from bits, except
as the unit of data length.


> > 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.

This is embedded realtime.  Built for speed, not comfort.  Yes, COTS
products aren't perfect.  Nothing is.  The language in which they are
written is irrelevant to their degree of perfection; it's a matter of how
much energy has or has not been spent on making the code work right.  If
we could find a perfect product, we would buy it.  And, yes, we do have to
debug the system before delivery.  So, debugging is critical to our
ability to deliver on time, etc. 


> > 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... :-)

We always claim we will.  Sometimes we do.  It depends on the
personalities and scars of the team leaders.   It took 6 to 9 months of
broken-record harping and deflection of off-the-point demonstrations
before the abject failure of that toolset became undeniable, even to those
in full denial.  The will to believe, and to just go along, is very
powerful.

Joe Gwinn