Re: ada and robots

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

Joe Gwinn wrote:

> OK.  Even if you choose to discount my experience as the blatherings of an
> idiot.  

Not at all. An idiot could not have pushed my hot buttons, because his
blatherings would carry no weight. When an intelligent and thoughtful
engineer voices criticisms that are based on outdated information and/or
possible misunderstanding of the technology, that's when my hot buttons
get pushed.

Well, that's no excuse for be to go off the handle. It was hypocritical
of me to complain about personal attacks, and then engage in one, all on
the same day. For that I do apologize. However, with all due respect, I
believe your statements do a disservice to both the past situation with
Ada83, and the current situation with Ada95.

> But remember, I don't have to convince you of anything.  I do have
> to deliver a working, reliable product.

Fair enough.

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

This situation was lamentable for Ada83, but it is rapidly improving for
Ada95.

> As for Ada83 experience, I have (or know of) both old and new experience,

If you have _new_ experience with Ada83, that's a problem you need to
solve as soon as you can. The Ada95 compilers out there (especially
GNAT) are a vast improvement over those that were available for Ada83.
And Ada95 is the standard now; Ada _is_ Ada95.

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

I think you're overplaying the difficulties, even those that might have
existed in the past.  They might actually have been trivial to solve
even in Ada83, but they would have seemed insurmountable to anyone not
really motivated to find the Ada83 solution. In any event, early
experiences with Ada95 have indicated that it can do the job, so there
seems little point in bemoaning deficiencies (real or perceived) in
Ada83. 

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

Always an option, but then such bits should be isolated as quickly as
possible and encapsulated into abstractions which can then be used by
the application logic (which would still represent the bulk of the
program). This is not an argument against writing a hardware control
application in Ada, it only argues that there may be isolated
specialized control functions that can only be done via assembly (in
which case, machine-code insertions would seem ideal). But it is not
clear whether even that much was really necessary in Ada83, and of
course it says nothing about Ada95...

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

What bothers me about this is that, although you had some negative
experiences with some poor implementations of Ada83, you've also had
some positive experiences with some better implementations of Ada83.
This would argue that the problems you encountered were due to the
quality of particular implementations, not the suitability of the
language itself. Yet, despite this, your predisposition seems to be to
make blanket negative statements about the language. This is why I
suspect a purely cultural prejudice is at work here.

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

Surely pragma Volatile would have cured this? (Even in Ada83?)

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

Fine, reuse is always preferable to writing from scratch. But this says
nothing about the suitability of Ada for low-level hardware control
where a base of driver software does not already exist.

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

As you start getting some new Ada95 systems in (or just go ahead and
download GNAT and start playing :-) ), be sure to re-evaluate some of
those "inappropriate features" that might have bit you in the past. In
all likelihood, they were just a symptom of the poor quality of some of
the implementations back then. You may be quite surprised how good their
performance is today.

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

My point was that your information is out-of-date, yet you used it to
cast a general indictment of Ada83, and by implication Ada95.  When you
say that others have "claimed" Ada95 is better, but you can't
substantiate those claims, the implication is that those cannot be
substantiated. They can.

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

Do the benchmarking, but don't be afraid to try the new features. Of
course, it does depend on the compiler, but some of those new features
(e.g., protected types rather than passive tasks) can allow you to
improve your software designs right now.

> > However, in my experience, it's always been the _abstractions_ that have
> > saved my butt... [snip] ... 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.

Not in my experience. For better or worse, each language has an attached
culture that influences the quality of the engineers trained to program
in it. I've found that programmers with Ada experience were generally
better abstractionists than those with C experience.  I would trust an
Ada programmer programming in C much farther than a C programmer trying
to program in Ada.


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

Over-reliance on debugging is a cost-and-schedule black hole. A much
more profitable course is to: (1) demand excellent documentation of the
behavior of third-party COTS components; (2) regardless of the quality
of such documentation, rigorously test and benchmark the COTS components
to establish their actual behavior _before_ attempting to integrate
them; (3) for the application code, use technical peer reviews
("walkthroughs") at all stages of development -- requirements, design,
and coding -- to catch software flaws as early in the pipeline as
possible (the earlier an error is detected, the cheaper it is to fix);
(4) perform black-box unit testing on the host system for everything
except the lowest-level hardware-specific code (and even for the latter,
it is often useful to build a software simulation of the target hardware
and test against that); (4) use debugging-on-target only as a _very_
last resort. 

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

Just for the record, are you still talking about an Ada toolset here, or
about some set of COTS products?  If the former, it would be helpful to
this newsgroup if you identified it, so it can be avoided. We'll
understand, however, if you are reluctant to name names.

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