Re: += in ada

["Robert I. Eachus" <rieachus@comcast.net>]

Russ wrote:

> I simply do not understand your reasoning here. How does "+=" (or
> ":+") have any more side effects than "Inc" or "++"? They are all just
> procedures. Please give me an example where "+=" has a side effect
> that "Inc" or "++" cannot have. Until you do, I think you may have
> just exposed the irrationality of your objection to augmented
> assignment operators.

This is what you continue to just not get.  Either the addition is a 
side effect of the assignment, or the assignment is a side effect of the 
addition.  I don't care that you don't think that way.  My point is that 
Ada programmers think that way, and it makes += very ugly.  It may be, 
from your point of view, irrational, stupid, crazy, etc., but I don't 
care.  Nor do most Ada programmers.

> Yes, and there is a huge difference between 100000.0 and 1000000.0
> too.

Which is why Ada programmers would not write either.  We could get into 
a long discussion about breaking such literals into groups of three, 
four or even five characters.  Ada programmers would be glad to oblidge. 
  But most, if not all Ada programmers would see:

Big: constant := 100000.0;
Bigger: constant := 1000000.0;

as wrong, whereas

Big: constant := 100_000.0;
Bigger: constant := 1000_000.0;

vs:

Big: constant := 100_000.0;
Bigger: constant := 1_000_000.0;

...would be seen as a style issue--and wrong if the project had an 
agreed style in this area.

> As I said before, I am not a professional programmer or computer
> scientist. I am aerospace engineer working on future concepts for
> safety critical air traffic management systems 20 years in the future.
> I would like to think that Ada will be an option when the time comes
> to implement my concepts, but I am losing hope.
> 
> Because my formal training is not in programming or computer science,
> I have restricted my comments on Ada to relatively low-level aspects
> of the language. I don't consider myself qualified to comment on more
> complicated issues. However, judging by my experience here, I am
> losing faith in the Ada community. If you can't get the little things
> right, how in the world can you can the complicated things right? I
> don't think you can, and I don't think you will.
> 
> I have read several times here that augmented assignment operators are
> a "non-starter", but I have yet to read any good reason why, other
> than the lack of manpower in the Ada world. That tells me that Ada is
> over the hill. Yesterday's news. Ossified. Ada is a legacy language.
> RIP.

And, as I said, you still don't get it.  Ada had those arguments, lots 
of them, to boring extremes.  I remember one point where I was getting 
new draft Reference Manual chapters every few weeks, and often the 
comments on a new draft would be longer than the draft within the first 
week.  I once sent in fifty pages of comments in one email, then Mike 
Woodger outdid me by sending in a longer set of comments--all about 
commas vs. semicolons and other detailed punctuation issues in the text.

Ada has adopted a consistant style.  As you should be able to see, there 
are still arguments on the margins, like overloading To_String and 
To_Unbounded_String with unary "+", or adding Inc for integer types. 
But changing style to the extent implied by your comments would be a 
Richter scale magnitude 9.5 earthquake at the foundations of the the 
language structure.  It won't happen.  Other languages have those 
notations, Ada doesn't.  Ada allows underscores in numeric literals, 
other languages allow commas, or nothing at all.  And so on.

At a certain point, you are not changing the language, you are inventing 
a new one.  Get over it.




-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig