C++ vs. Ada -- Is Ada loosing?

C++ vs. Ada -- Is Ada loosing?

[happy.colorado.edu!srheintze]

There are a lot of people out there who think C++ is the greatest thing since
sliced bread.  C++ is a truly wonderful toy because you can redefine the
language for your application.  

For example you can provide the function that is invoked in response to
assignment so you can optimize your matrix class to (1) only pass a pointer to
the matrix data instead of actually making a physical copy and (2) defer the
actual copy operation to the point in time when (and if) the target of the
assignment is modified.  This is impressive.

HOWEVER, please read "A dynamic Vector is harder than it looks" from the June
1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4. 
*THIS ARTICLE IS SCARY*  Basically Tom Cargill pointed out a bug that nearly
all C++ textbooks have made when they implement a dynamically sized array. 
This includes the textbook written by the implementor of the AT&T Cfront
compiler (will I get in trouble if I mention his name?).  If the language is so
convoluted that even the experts (including the compiler writers) cannot get
their simple textbook examples correct, then I conclude there is something
drastically wrong with the language.

I don't want anybody writing code in C++ for satellites funded with my tax
dollars!

I heard a rumer about a multi-million (or multi-billion) dollar satellite going
astray because some one left a comma out of a FORTRAN DO loop and it was still
syntactically legal.  Can anybody give me a reference on this?  

So we have C++ with very similar problems to this problem in FORTRAN that (I
believe, correct me if I am wrong) Ada was supposed to solve. You can insert a
";" between the ")" and the "{" in any while or if statement and the C++
program is still syntactically correct but semantically disasterous.

So, Ada was on the seen.  I spent some significant time as a project lead with
Ada in '89-90.  I was excited about the language.  Now I am independent and
make my living with C++.  

Where is Ada going?  Is it dying? That thread on "Is GNU-Ada self-insulting"
suggests that Ada is floundering. How badly is Ada floundering? Does that mean
I'll never see inheritance in Ada?

			Thanks,
				Sieg

Re: C++ vs. Ada -- Is Ada loosing?

[robin.vowels]

On Saturday, December 5, 1992 at 7:18:16 AM UTC+11, srhe...@happy.colorado.edu wrote:
> There are a lot of people out there who think C++ is the greatest thing since
> sliced bread.  C++ is a truly wonderful toy because you can redefine the
> language for your application.  
> 
> For example you can provide the function that is invoked in response to
> assignment so you can optimize your matrix class to (1) only pass a pointer to
> the matrix data instead of actually making a physical copy and (2) defer the
> actual copy operation to the point in time when (and if) the target of the
> assignment is modified.  This is impressive.
> 
> HOWEVER, please read "A dynamic Vector is harder than it looks" from the June
> 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4. 
> *THIS ARTICLE IS SCARY*  Basically Tom Cargill pointed out a bug that nearly
> all C++ textbooks have made when they implement a dynamically sized array. 
> This includes the textbook written by the implementor of the AT&T Cfront
> compiler (will I get in trouble if I mention his name?).  If the language is so
> convoluted that even the experts (including the compiler writers) cannot get
> their simple textbook examples correct, then I conclude there is something
> drastically wrong with the language.
> 
> I don't want anybody writing code in C++ for satellites funded with my tax
> dollars!
> 
> I heard a rumer about a multi-million (or multi-billion) dollar satellite going
> astray because some one left a comma out of a FORTRAN DO loop and it was still
> syntactically legal.  Can anybody give me a reference on this?

I think that you are referring to a DO statement like:

DO 50 I = 1.20

instead of

DO 50 I = 1,20

In FORTRAN 77, both statements are correct.
They are correct because spaces are ignored, but the first statement
is an assignment statement, viz,

DO50I = 1.20

not a loop control statement, and without any structure on a DO loop
(there's no END of loop statement) the error could not be diagnosed
by a compiler.

If this was reported as a real event, this info may help you to
find it.

> So we have C++ with very similar problems to this problem in FORTRAN that (I
> believe, correct me if I am wrong) Ada was supposed to solve. You can insert a
> ";" between the ")" and the "{" in any while or if statement and the C++
> program is still syntactically correct but semantically disasterous.
> 
> So, Ada was on the seen.  I spent some significant time as a project lead with
> Ada in '89-90.  I was excited about the language.  Now I am independent and
> make my living with C++.  
> 
> Where is Ada going?  Is it dying? That thread on "Is GNU-Ada self-insulting"
> suggests that Ada is floundering. How badly is Ada floundering? Does that mean
> I'll never see inheritance in Ada?
> 
> 			Thanks,
> 				Sieg

Re: C++ vs. Ada -- Is Ada loosing?

[Shark8]

On Thursday, August 8, 2019 at 9:23:47 AM UTC-6, robin...@gmail.com wrote:
> On Saturday, December 5, 1992 at 7:18:16 AM UTC+11, srhe...@happy.colorado.edu wrote:
> > 
> > HOWEVER, please read "A dynamic Vector is harder than it looks" from the June
> > 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4. 
> > *THIS ARTICLE IS SCARY*  Basically Tom Cargill pointed out a bug that nearly
> > all C++ textbooks have made when they implement a dynamically sized array. 
> > This includes the textbook written by the implementor of the AT&T Cfront
> > compiler (will I get in trouble if I mention his name?).  If the language is so
> > convoluted that even the experts (including the compiler writers) cannot get
> > their simple textbook examples correct, then I conclude there is something
> > drastically wrong with the language.

For those interested, the sited paper can be read here:
https://drive.google.com/open?id=1PHUleua3FpIYRrumkboxBCLhMjc_mkxj

Re: Marina 1 / FORTRAN bug

[robin.vowels]

On Saturday, December 5, 1992 at 7:18:16 AM UTC+11, srhe...@happy.colorado.edu wrote:

> I heard a rumer about a multi-million (or multi-billion) dollar satellite going
> astray because some one left a comma out of a FORTRAN DO loop and it was still
> syntactically legal.  Can anybody give me a reference on this?  

A google search produced this first try:


This has come up in a couple of threads in the last month or two, so I finally got around to looking it up. The famous FORTRAN punctuation error occured on Mariner 1 in 1962. Here is a description of the error:

"There is a useful lesson to be learned from the failure of one of the earliest planetary probes launched by NASA. The cause of the failure was eventually traced to a statement in its control software similar to this:

DO 15 I = 1.100

when what should have been written was:

DO 15 I = 1,100

but somehow a dot had replaced the comma. Because Fortran ignores spaces, this was seen by the compiler as:

DO15I = 1.100
which is a perfectly valid assignment to a variable called DO15I and not at all what was intended."

Information found here:

http://www.star.le.ac.uk/~cgp/prof77.html#tth_sEc1.3

Re: Mariner 1 / FORTRAN bug

[Jeffrey R. Carter]

On 8/8/19 5:40 PM, robin.vowels@gmail.com wrote:
> 
> DO 15 I = 1.100
> 
> when what should have been written was:
> 
> DO 15 I = 1,100
> 
> but somehow a dot had replaced the comma. Because Fortran ignores spaces, this was seen by the compiler as:
> 
> DO15I = 1.100
> which is a perfectly valid assignment to a variable called DO15I and not at all what was intended."

Some people on here may not be aware that FORTRAN did not require declaration of 
variables, so the above would create a new variable DO15I. I don't know what 
flavor of FORTRAN was used in Mariner 1, but FORTRAN 66 added the IMPLICIT 
statement, which declared the type used for undeclared variables. Adding 
IMPLICIT LOGICAL A-Z at the beginning of your code helped to catch these kinds 
of things. FORTRAN 77 added IMPLICIT NONE, which required you to declare all 
variables. Sometime in the late 1970s-early 1980s people moved away from punched 
cards in ALL UPPER CASE and started calling the language Fortran.

Given the kind of testing such software would have undergone, I somehow doubt 
that an absence of looping would have gone unnoticed, so I suspect this story is 
apocryphal. While it probably didn't cause the failure of a space probe, people 
did get bitten by this language design flaw, which is an example of a 
single-character error (added, omitted, or changed) that results in valid code. 
This is something that competent language designers go to great lengths to 
avoid. Note that C and most of its descendants (most of the commonly used 
languages today) have this flaw.

-- 
Jeff Carter
"I like it when the support group complains that they have
insufficient data on mean time to repair bugs in Ada software."
Robert I. Eachus
91

Re: Mariner 1 / FORTRAN bug

[robin.vowels]

On Friday, August 9, 2019 at 3:26:30 AM UTC+10, Jeffrey R. Carter wrote:
> On 8/8/19 5:40 PM, r......@gmail.com wrote:
> > 
> > DO 15 I = 1.100
> > 
> > when what should have been written was:
> > 
> > DO 15 I = 1,100
> > 
> > but somehow a dot had replaced the comma. Because Fortran ignores spaces, this was seen by the compiler as:
> > 
> > DO15I = 1.100
> > which is a perfectly valid assignment to a variable called DO15I and not at all what was intended."
> 
> Some people on here may not be aware that FORTRAN did not require declaration of 
> variables,

It still doesn't.

> so the above would create a new variable DO15I. I don't know what 
> flavor of FORTRAN was used in Mariner 1,

Marina 1 (1962) preceded FORTRAN 66.

> but FORTRAN 66 added the IMPLICIT 
> statement, which declared the type used for undeclared variables. Adding 
> IMPLICIT LOGICAL A-Z at the beginning of your code helped to catch these kinds 
> of things. FORTRAN 77 added IMPLICIT NONE, which required you to declare all 
> variables.

IMPLICIT NONE is an optional statement. If is is omitted,
variables do not need to be declared.

> Sometime in the late 1970s-early 1980s people moved away from punched 
> cards in ALL UPPER CASE and started calling the language Fortran.
> 
> Given the kind of testing such software would have undergone, I somehow doubt 
> that an absence of looping would have gone unnoticed,

If you read further on past the referenced article, you will see that
the looping DID go unnoticed. [try google]

> so I suspect this story is 
> apocryphal.

It wasn't.

> While it probably didn't cause the failure of a space probe, people 
> did get bitten by this language design flaw, which is an example of a 
> single-character error (added, omitted, or changed) that results in valid
> code.

Single-character errors are still possible, whatever the language.

> This is something that competent language designers go to great lengths to 
> avoid. Note that C and most of its descendants (most of the commonly used 
> languages today) have this flaw.

Re: Mariner 1 / FORTRAN bug

[J-P. Rosen]

Le 09/08/2019 à 03:57, robin.vowels@gmail.com a écrit :
>> While it probably didn't cause the failure of a space probe, people 
>> did get bitten by this language design flaw, which is an example of a 
>> single-character error (added, omitted, or changed) that results in valid
>> code.
> Single-character errors are still possible, whatever the language.
> 
Of course, you can type "-" instead of "+" in any language.

But outside of mathematical formulas, can you give an example of
single-character error in Ada?

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Mariner 1 / FORTRAN bug

[Niklas Holsti]

On 19-08-09 09:28 , J-P. Rosen wrote:
> Le 09/08/2019 à 03:57, robin.vowels@gmail.com a écrit :
>>> While it probably didn't cause the failure of a space probe, people
>>> did get bitten by this language design flaw, which is an example of a
>>> single-character error (added, omitted, or changed) that results in valid
>>> code.
>> Single-character errors are still possible, whatever the language.
>>
> Of course, you can type "-" instead of "+" in any language.
>
> But outside of mathematical formulas, can you give an example of
> single-character error in Ada?

I once declared a record type that contained a component, aptly (I 
thought) called Address, of type System.Address.

Then, in a certain statement dealing with a record object R of that 
type, I mistakenly wrote

    R'Address

when I meant

    R.Address

Silly me.

I now have a personal coding rule: never use the name Address for a 
record component of type System.Address. Perhaps this should be expanded 
to forbid using any record-attribute name as a component name; for 
example, Size.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Mariner 1 / FORTRAN bug

[J-P. Rosen]

Le 09/08/2019 à 08:47, Niklas Holsti a écrit :
> I now have a personal coding rule: never use the name Address for a
> record component of type System.Address. Perhaps this should be expanded
> to forbid using any record-attribute name as a component name; for
> example, Size.
Shameless plug: which can be easily enforced by AdaControl...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Mariner 1 / FORTRAN bug

[Jeffrey R. Carter]

On 8/9/19 8:47 AM, Niklas Holsti wrote:
> On 19-08-09 09:28 , J-P. Rosen wrote:
>> Le 09/08/2019 à 03:57, robin.vowels@gmail.com a écrit :
>>>> While it probably didn't cause the failure of a space probe, people
>>>> did get bitten by this language design flaw, which is an example of a
>>>> single-character error (added, omitted, or changed) that results in valid
>>>> code.
>>> Single-character errors are still possible, whatever the language.
>>>
>> Of course, you can type "-" instead of "+" in any language.
>>
>> But outside of mathematical formulas, can you give an example of
>> single-character error in Ada?
> 
> I once declared a record type that contained a component, aptly (I thought) 
> called Address, of type System.Address.
> 
> Then, in a certain statement dealing with a record object R of that type, I 
> mistakenly wrote
> 
>     R'Address
> 
> when I meant
> 
>     R.Address

AIUI, a single-character error in a language design is one that is possible 
regardless of the developer's choice of identifiers. By that criterion, this is 
not a single-character error in the language design. Compare it to =/== in C and 
its descendants.

-- 
Jeff Carter
"[A] brilliant military career that after thirty
years catapulted him to the rank of corporal."
Take the Money and Run
138

Re: Mariner 1 / FORTRAN bug

[Maciej Sobczak]

> But outside of mathematical formulas, can you give an example of
> single-character error in Ada?

with Ada.Text_IO;

procedure Test is

   procedure P (I, J : Integer) is
   begin
      Ada.Text_IO.Put_Line ("Killing people");
   end;

   procedure P (f : Float) is
   begin
      Ada.Text_IO.Put_Line ("Not killing people");
   end;

begin
   P (1,2); -- or should it be P (1.2); ?
end;

And of course we have to implement the Initialise operation for our Controlled types, right?

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Mariner 1 / FORTRAN bug

[Nasser M. Abbasi]

On 8/9/2019 3:38 AM, Maciej Sobczak wrote:
>> But outside of mathematical formulas, can you give an example of
>> single-character error in Ada?
> 
> with Ada.Text_IO;
> 
> procedure Test is
> 
>     procedure P (I, J : Integer) is
>     begin
>        Ada.Text_IO.Put_Line ("Killing people");
>     end;
> 
>     procedure P (f : Float) is
>     begin
>        Ada.Text_IO.Put_Line ("Not killing people");
>     end;
> 
> begin
>     P (1,2); -- or should it be P (1.2); ?
> end;
> 
> And of course we have to implement the Initialise operation for our Controlled types, right?
> 

That is why using named arguments is better and also more clear

    P (I=>1, J=>2);

No chance to mix it up with

    P (f=>1.2);

--Nasser

Re: Mariner 1 / FORTRAN bug

[Maciej Sobczak]

> That is why using named arguments is better and also more clear
> 
>     P (I=>1, J=>2);

Of course - the best way to avoid writing bad code is to write good code. But this is true in any language. What we should expect from good languages is that bad code should be impossible, or at least writing bad code should take more effort than writing good code. And yet, what the above example shows, bad code is perfectly possible in Ada and in fact is easier - and that good code involves higher effort.

Which, ultimately, makes it more difficult for Ada to gain attention of C++ programmers, for example.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Mariner 1 / FORTRAN bug

[Lucretia]

On Friday, 9 August 2019 22:05:40 UTC+1, Maciej Sobczak  wrote:
> > That is why using named arguments is better and also more clear
> > 
> >     P (I=>1, J=>2);
> 
> Of course - the best way to avoid writing bad code is to write good code. But this is true in any language. What we should expect from good languages is that bad code should be impossible, or at least writing bad code should take more effort than writing good code. And yet, what the above example shows, bad code is perfectly possible in Ada and in fact is easier - and that good code involves higher effort.
> 
> Which, ultimately, makes it more difficult for Ada to gain attention of C++ programmers, for example.

You could always have a enforce named parameters compiler option, don't know if GNAT has that, which would piss off most people if there was no editor assistance to fill that in for you.

Luke.

Re: Mariner 1 / FORTRAN bug

[Paul Rubin]

Lucretia <laguest9000@googlemail.com> writes:
> You could always have a enforce named parameters compiler option,

Putting a space after the comma is generally good style and some linters
enforce or at least suggest it.  So P(1, 2) is valid but P(1. 2) should
be a syntax error.

It's interesting to hear that using named parameters at the call site is
considered good Ada style.  In Haskell and C++ one sometimes uses
separate types for the args to make sure they get passed in the right order.

Re: Mariner 1 / FORTRAN bug

[Keith Thompson]

robin.vowels@gmail.com writes:
> On Saturday, December 5, 1992 at 7:18:16 AM UTC+11, srhe...@happy.colorado.edu wrote:
>
>> I heard a rumer about a multi-million (or multi-billion) dollar satellite going
>> astray because some one left a comma out of a FORTRAN DO loop and it was still
>> syntactically legal.  Can anybody give me a reference on this?  
>
> A google search produced this first try:
>
>
> This has come up in a couple of threads in the last month or two, so I
> finally got around to looking it up. The famous FORTRAN punctuation
> error occured on Mariner 1 in 1962. Here is a description of the
> error:
>
> "There is a useful lesson to be learned from the failure of one of the
>earliest planetary probes launched by NASA. The cause of the failure
>was eventually traced to a statement in its control software similar to
>this:
>
> DO 15 I = 1.100
>
> when what should have been written was:
>
> DO 15 I = 1,100
>
> but somehow a dot had replaced the comma. Because Fortran ignores
> spaces, this was seen by the compiler as:
>
> DO15I = 1.100
> which is a perfectly valid assignment to a variable called DO15I and
> not at all what was intended."
>
> Information found here:
>
> http://www.star.le.ac.uk/~cgp/prof77.html#tth_sEc1.3

According to https://en.wikipedia.org/wiki/Mariner_1 :

    In other accounts, the bug consisted of:

    * a period typed in place of a comma, causing a FORTRAN DO loop
      statement to be misinterpreted (although there is no evidence that
      FORTRAN was used in the mission), of the form "DO 5  K=1. 3"
      interpreted as assignment "DO5K = 1.3" There are anecdotal
      reports that there was in fact such a bug in a NASA orbit
      computation program at about this time, but it was a program for
      Project Mercury, not Mariner, and the claim was that the bug was
      noticed and fixed before any serious consequences resulted.

Also discussed on RISKS Digest, including an account from someone who
worked at NASA in 1963.  The error caused a DO loop to execute just once
rather than iterating to a more precise solution.  The resulting
calculation was good enough for the Mercury suborbital flights, but not
for the later orbital flights.

http://catless.ncl.ac.uk/Risks/9.54.html#subj1.1

And see here:
http://catless.ncl.ac.uk/Risks/8/75#subj1
for a description of a missing "bar" in a hand-written calculation that
apparently caused the loss of the Mariner 1 Venus probe in 1962.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */