Mutations and type usage in Ada

Mutations and type usage in Ada

[Derek M. Jones]

All,

To what extent will Ada type checking cause mutated
programs, where some of the variables have been changed,
to be flagged at compile time?

I have had people tell me stories of mutated Fortran and C
programs successfully compiling and passing all the test
cases (I have had no luck tracking down papers giving details;
most papers discuss what happens when operators are changed,
statement deleted, etc; I am interested in what happens when
just the variables are changed).

Does anybody know of any mutation work with Ada that involves
changing the variables?

Whether or not a change of variable will result in a compile
time error will depend on the extent to which a program makes
use of the Ada type system.  For instance, if all my variables
have type integer then the switching them around is unlikely
to generate a compile time message.

Does anybody know of any measurements of Ada source that have looked
at how 'strongly' they are typed?  That is, do many developers
use integer everywhere, or do that always create a new type for
everything?

My experience with Pascal (yes, Pascal is not Ada) was that many
programmers would not spend the time needed to think about the
type that needed to be created.  Perhaps some of these people have
been sucked into Ada and managed to avoid the 'type safety' thought
police :-)

Re: Mutations and type usage in Ada

[Larry Kilgallen]

In article <aY2If.25669$i2.16979@newsfe6-gui.ntli.net>, "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> writes:

> My experience with Pascal (yes, Pascal is not Ada) was that many
> programmers would not spend the time needed to think about the
> type that needed to be created.

If such work passes peer review, then there is a management problem.

Re: Mutations and type usage in Ada

[Jeffrey R. Carter]

Larry Kilgallen wrote:

> If such work passes peer review, then there is a management problem.

A review by the peers ("equals") of such a person will not catch the problem, 
since such peers, by definition, make the same mistake and see nothing wrong in it.

-- 
Jeff Carter
"Every sperm is sacred."
Monty Python's the Meaning of Life
55

Re: Mutations and type usage in Ada

[Mark Lorenzen]

"Jeffrey R. Carter" <spam@spam.com> writes:

> Larry Kilgallen wrote:
> 
> > If such work passes peer review, then there is a management problem.
> 
> A review by the peers ("equals") of such a person will not catch the
> problem, since such peers, by definition, make the same mistake and
> see nothing wrong in it.

Excellent comment!

- Mark

Re: Mutations and type usage in Ada

[Larry Kilgallen]

In article <Ou4If.1322$JR6.1102@newsread3.news.pas.earthlink.net>, "Jeffrey R. Carter" <spam@spam.com> writes:
> Larry Kilgallen wrote:
> 
>> If such work passes peer review, then there is a management problem.
> 
> A review by the peers ("equals") of such a person will not catch the problem, 
> since such peers, by definition, make the same mistake and see nothing wrong in it.

Meaning there was a management failure in training/hiring/firing.

Re: Mutations and type usage in Ada

[Jeffrey R. Carter]

Larry Kilgallen wrote:

> Meaning there was a management failure in training/hiring/firing.

Right. But that occurs long before the incompetent coder's code gets to peer review.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09

Re: Mutations and type usage in Ada

[adaworks]

"Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> wrote in message
news:aY2If.25669$i2.16979@newsfe6-gui.ntli.net...
> All,
>
> To what extent will Ada type checking cause mutated
> programs, where some of the variables have been changed,
> to be flagged at compile time?
>
It is not entirely clear what problem you are trying to solve.
>
> Whether or not a change of variable will result in a compile
> time error will depend on the extent to which a program makes
> use of the Ada type system.  For instance, if all my variables
> have type integer then the switching them around is unlikely
> to generate a compile time message.
>
In Ada we would typically eschew the use of predefined types
for production code.  The Integer type is useful for student
and toy programs but not for serious programs.   Often, we
will specify not only the range of the type but also supply a
representation specification to define its bit size.
>
> My experience with Pascal (yes, Pascal is not Ada) was that many
> programmers would not spend the time needed to think about the
> type that needed to be created.  Perhaps some of these people have
> been sucked into Ada and managed to avoid the 'type safety' thought
> police :-)
>
What a strange phrase, "type safety thought police."

The objective, I would hope, is to produce the most dependable software
we can.   We want to solve the right problem and we want to solve it
correctly.   Further, we want to include all the controls over that solution
that will ensure it will not inadvertantly go awry during operation.

Ada provides a variety of tools for ensuring dependability.   Those tools
include type safety and visibility safety.   The language tools alone are not
sufficient for ensuring dependability.  We still need inspection by humans,
testing, and lots of other tools that are outside the language.   In the case
of Ada, correct use of the tools provided by the language, including type
safety, can help in the use of those other tools.

If you are simply concerned with writing a program according to your own
best understanding of the problem, you might use any language tool or
limited set of tools you wish.   On the other hand, if you are concerned with
an engineering view of the problem, which includes the long-term maintenance
of the solution, it is only proper to choose your tools wisely and use them
correctly.

Introducing phrases such as "type safety thought police" is both irresponsible
and silly.  It reflects a narrow view of what software engineering is about and
has the potential for leading astray those newcomers to software engineering
that need to be prepared for correct use of all the tools available to them
in their work.

Richard Riehle