From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c78177ec2e61f4ac
X-Google-Attributes: gid103376,public
From: gwinn@res.ray.com (Joe Gwinn)
Subject: Re: ada and robots
Date: 1997/06/09
Message-ID: <gwinn-0906971938380001@dh5055133.res.ray.com>
X-Deja-AN: 251095553
References: <338CDA96.53EA@halcyon.com> <338F5D7D.6C03@tiac.net>
 <338F9D05.5EB3@bix.com> <5mqpj3$bc5$1@goanna.cs.rmit.edu.au>
 <33930245.12A1@sprintmail.com> <5mv984$7kn@news.emi.com>
 <gwinn-0306971836410001@smc19.ed.ray.com> <33961528.2A9A@sprintmail.com>
 <9706052229.AA29554@jaguar.nmc.ed.ray.com> <3398E102.54CF@sprintmail.com>
Organization: Raytheon Electronic Systems
Newsgroups: comp.lang.ada
Date: 1997-06-09T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <3398E102.54CF@sprintmail.com>, johnvolan@sprintmail.com wrote:

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

All information is outdated.  It's only a matter of how much so.

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

Accepted.


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

I've been hyped at a few times too many over the years.  I'll believe the
problems are fixed when I see that they are fixed, in my own lab.


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

So many people are saying.  We shall see; our experiments are just
beginning.  However, direct control of hardware by Ada is not in our
architecture, as only VxWorks I/O drivers are permitted to touch the
metal, so that issue will not be tested.


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

Our current (as of last week) experience with Ada83 is that the generated
code is *very* slow; this is why we are flirting with Ada95, which appears
to be a factor faster.  C is a bit faster still than Ada95, but not so
much that one would choose one over the other on that alone.  When the
experiments are complete, I may publish actual test results.  


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

See above.  By "reliable", I also meant to include "portable".  Even if I
got it to work under one compiler, the next one has its own set of
oddities.  See below.


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

With the Ada83 compilers of our experience, except for SD Ada, it *was*
necessary, and so it was safer to simply have a few assembly-coded (or
C-coded) machine control subroutines.  

I guess I don't see why people are so hard over on defending Ada here. 
It's not like we are talking about much code, and the only traditional HOL
intended to do anything like this is C, which is why one generally did
this stuff in assembly.  The fact that in my experience Ada doesn't do
hardware control well isn't a reason to use or not use Ada for a project,
and I have no religious objection to use of multiple languages in a
project.

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

I guess that all but one then implementation of Ada83 was poor, then.  I
don't know that much has changed, because the Ada compiler vendors have
put their efforts into Ada95, leaving Ada83 on maintenance.  As one would
expect.  And certainly what the newsgroup is saying.


> > 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 theory, it should have.  However, only SD and perhaps DEC got the
meaning of "volatile" completely correct, so we couldn't depend on it, and
so couldn't use it.  Back to assembly.


> > 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 didn't claim that it did.  Our project is what it is.


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

I'm not sure we have the budget or schedule for much playing, but some
will be done, under the rubric "pathfinding".

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

I said just what I said, and implied nothing.  I thought I was quite clear
about what was known and what was rumoured.

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

Actually, the benchmarks must stay in the Ada83 subset of Ada95, which is
after all the bulk of Ada95, so that we can directly compare performance,
size, etc.  The benchmarks are reasonably large bits of actual application
code, which wouldn't have any reason to use the new parts of Ada95 anyway.


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

In my experience, the best programmers were able to rise above the here
and now of whichever language and operating system they were then using. 
I don't know that I believe that any language, however good, can make good
programmers from bad programmers.  It's only a language.


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

Well, it's a nice theory.  Would that it were true in practice.  Somehow,
we always seem to end up in the lab at 3:00 AM.  If we were only smarter.


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

Both; they are one in the same.  You have heard of them, too.

I don't know that I could afford the libel suit, even if I won it.  


Joe Gwinn