Re: Any research putting c above ada?

[Roy Grimm <ragrimm@cca.rockwell.com>]

Kaz Kylheku wrote:
>
> >In Ada you can restrict the user from assigning between incompatible types,
> >you can data hide etc etc.
> 
> This is true of C as well. Assigning between incompatible types is a constraint
> violation which *requires* a diagnostic. It's all in ISO 9899:1990.

There is a subtle difference you are missing here.  In Ada, any type
_difference_ will cause a compile time error.  In C, the type
_incompatibilities_ are the only things to be caught.  What is the point
of defining different types if you can freely assign between them? 
Different types are used for different purposes.  Removing that checking
eliminates the structure that makes Ada so much easier to debug. 
 
> >The bug count and cost of Ada is much less than that of C, just because some
> >of the bugs that occur regularly in C (int a[10]; a[10] = 4; anyone ?)
> >cannot
> 
> I believe it, but you are not describing the actual advantages of Ada over C.

What would you rather do?  Develop software or chase after bugs? 
Personally, I'd rather spend my time productively producing instead of
explaining to my boss why I spent two weeks on an array index that went
out of bounds.  Wouldn't you consider that an advantage?
 
> >C:
> >typedef int cleared_flight_level;
> >typedef int airspeed;
> >
> >airspeed a = 4;
> >cleared_flight_level cfl = 5;
> >
> >...
> >
> >cfl = a;
> 
> What is your point here? The two types here are compatible. You have only
> created an alias name for int. In other words, C has structural equivalence
> for types (other than structs).

That's just the point.  The types are not compatible.  They use numbers
to represent two completely different things that _must_ be separated at
a conceptual level.  If you've ever worked on a mission critical system,
such as a flight computer, you would understand what is being talking
about.

> Why don't you see a type violation in the very declarations?

Because numerical constants which are not typed can be assigned to
numerical variables.  The numerical constant is assigned a type at
compile time when it is being assigned to a particular variable. 
Besides, the declarations probably wouldn't make it through code
review.  The team would make the programmer go back and put in type
defined numerical constants.

> In C you can do this:
> 
>     typedef struct airspeed { int i } airspeed;
>     typedef struct cleared_flight_level { int i } cleared_flight_level;
> 
> There you go. The two are no longer assignment compatible with each other or
> with the int type. You can still assign an airspeed to an other airspeed, and
> pass it in and out of functions by value. The .i operation converts
> an airspeed to an int.

Why take the long road every time?  Why not use a C compiler which
enforces the additional required structure?  It would make life so much
easier.

> >C is popular, it is quick and dirty, but I wouldn't like to trust my life to
> >it.
> 
> I wouldn't trust my life to any computer system, especially if it had ``Intel
> inside''.

Have you flown on any major commercial airplanes in the last 10 years? 
If so, you were trusting your life to Intel components.  Their ICs have
been running inside avionics equipment for years, with an extremely high
success rate.  Granted, the components which go into the systems are not
the commercial grade chips you find in a PC, but the mil-spec version of
those parts are in the flight computers world wide.

> There are too many things that can go wrong _beside_ programming
> errors. There is buggy hardware. There is also correct hardware which fails
> to be fault tolerant.  The sheer component count in a modern computer system
> is astounding, as is the small size of the individual components. Would you
> trust your life to a system in which an alpha particle emission can cause
> unpredictable behavior?

You think that modern flight computers are put on airplanes without
undergoing an entire suite of rigorous tests, including pushing them
beyond their limits to test the design?  Do you think that the potential
problems of the computers aren't planned for with redundant systems and
other forms of backup?  The systems can't be perfect.  But stop and
consider this:  You hear of PCs crashing every day.  It's an accepted
part of daily life.

Now ask yourself this:  How often do you hear of an airplane having a
computer problem?  How often do you see it on the news?  How often do
you hear of an avionics computer crashing and causing a plane crash? 
Once or twice a year?  Maybe less?  How many hours do planes spend in
the air compared to the problems they have?

Most of the computers on those airplanes have software developed in Ada.


--------------------------------------------------------------------
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com