Re: Does Ada still competitive?

[anon@att.net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 11376 bytes --]


Problem with 
Backward Compatibility:

100% backwards compatible is not a cost to be calculated and weighed it 
a requirement for all languages including, the spoken and written human
languages. Only sub-sets of the language can limit the usage of any 
language or statements. And once a word or statement is added it can never 
be deleted or its initial purpose removed. 

So, for an update to any computer language, it must be 100% backwards 
compatible with the previous version of the language.  If not then the 
update is to be known as a "new" language. And this standard is understood 
by all computer language designers, or updaters, like IBM, SUN, Miscrosoft, 
etc.

One example is that FORTRAN still allows the old arithmetic "if" statement 
without any compiler options. Even though most programmers, since FORTRAN 
77 have abandon that statement for the new powerfully "if-then-else" 
statement. But in keeping the old statement does allows FORTRAN to 
maintain its 100% backwards compatible.

And another example is JAVA which complies with this standard law for 
language. Yes it will complains when compiling a JAVA 1.00 routine or 
applet on an updated compiler such as Java 6 but the routine or applet 
will still compile and run. 

Then there Ada, when Ada 83 was updated to Ada 95, first the changes were 
explained in Annex J. "Obsolescent Features". One example was the Ada 
system libraries names, while Ada 83 use parent only names, Ada 95 
introduce parent.child names. Which meant for Ada 95 to be 100% backwards 
compatible in this case that any Ada compiler either had to provide the 
addition of the Ada 83 libraries (Best programming) or just specification 
files containing the routines names with "pragma Interface" (Ada 83) that 
would allow linkage into the Ada 95 libraries using "pragma Export" 
statements on the Ada 95 side, This would also keep any new Ada 95 or future 
features out of Ada 83 code (Good programming). But GNAT just use Ada 95 
with renaming statement which could allow some Ada 95 or later features 
into Ada 83 code (Bad programming). Actually to compile an Ada 83 library 
routine using GNAT way, means that the compiler is in error. An example is 
from "Text_IO.ads":

  pragma Ada_95;
  -------------
  warning pragma is not acknowledge in Ada 83. 
  
  -- Ada 83 only reports non-standardize pragmas RM 2.8. GNAT was not 
  -- available for Ada 83 so "pragma Ada_83" is an Ada 95 implementation
  -- statement. Aka this statement must have no effect on the compiler
  -- while compiling in Ada 83 mode.
  --
  -- note: if accepted under Ada 83 it would allow all feature of 
  -- Ada 95 to be used in Ada 83. (Very Bad programming design)
  -- for any Ada 83 only code

  with Ada.Text_IO;
       -------------
       illegal package name in Ada 83

  package Text_IO renames Ada.Text_IO;
                          -----------
                          illegal package name in Ada 83


In truth using pragma Ada_83 or Ada_95 does not guarantee that the 
GNAT compiler will see the correct version of Ada. And examples of 
this is in overloading the "=" function. In GNAT compiling using Ada 
83 option or pragma Ada_83 an "=" will accept any type. But in RM 83 
( 6.7 ) states the "=" "is only allowed if both parameters are of the 
same limited type." and the result must be Boolean, this was altered 
in Ada 95 to allow any type such as access type with result being any 
type.

An example that will compile in GNAT using "-gnat83"  but Ada 83 RM 
states it should not. So, the GNAT compiler should state:

 function "=" ( Left, Right : Integer_Access ) return Integer_Access ;
                              ---------------         --------------
                           RM 6.7 not a limited type
                           -- not an Ada 83 feature

                                                     RM 6.7 not Boolean
                                                  -- not an Ada 83 feature

Besides the overloading "=" error there is removal of a number of 
pragma statement in Ada 95, which were used by Cray and others in Ada 83. 
So, since Ada 95 is not 100% backwards compatible, so, Ada 95 should be 
classified as a new language that must complete with its predecessor 
Ada 83 but never replace it. 

And a number of changes in "Ada 2005" alters the Ada 95 statements 
which delete the 100% backwards compatible, so Ada 20056 is a new 
language.  And then there "Ada 2012 Corrigendum 1" also know as the 
"correction of errors" for Ada but instead of correcting some error it 
alters external Generic packages a big plus for Ada by replacing the 
"return by reference" by "return by type" causes existing re-usable  
external Generic packages to nolonger compile makes "Ada 2012" a completely 
100% new language that can never be 100% backwards compatible with any 
predecessor Ada 2005, Ada 95 or Ada 83.

So The ARG has not turn Ada language into four similar by different 
languages.

  Ada 83,   (adopted 1987)
  Ada 95,   (adopted 1995)
  Ada 2005, (adopted 2007)
  Ada 2012, (adopted 201?)

And No the ARG can not just pull Ada 83. Once a language has been 
created it there until the end of time. The ARG can only state that it is 
nolonger officially being supported any more by the ARG. But others like 
IBM for one can pick it up. IBM has done this for other languages.

The ARG says that each new Ada is only an upgrade. If that was the case,
then every statement every used in prior Ada version would still be 
operational in the updated version. Like "return by reference", would 
still be usable. And with almost every aspect of Ada now being optional, 
there is no true base standard that one can rely upon to use for the 
language.



Problem with 
Optimization:

Reference any and all "Software Optimization Reference Manual" or any 
chapters in a CPU designer manual's set that deals with Optimization. For 
Intel they use a manual, that can be download from Intel web site. 

 "Intel� 64 and IA-32 Architectures Optimization Reference Manual"

It states that any interruption in the execution stream, such as 
unnecessary verification checks decrease cpu performance and optimization.
Because it can cause the instruction pipelining as well as the memory 
caches to be flushed. And these type of statements can be found in SUN, 
SGI, IBM, and all others CPU manual set. And the "not null" feature is 
unnecessary aka a wasted code if the programmer designs his code 
correctly. Which makes the "not null" more of a high school teaching 
concept that should never be allowed in a language or production line 
compiler or language translator.

But since a number of ARG members are directly associated with Adacore. 
It seams ARG are not too concern with optimization because the 
optimization for GNAT, which is normally in the "Middle End" of a compiler 
is actually performed by the GCC backend which is not apart of GNAT Ada 
code. Plus secondary problem is that Adacode can not guarantee what code 
will be produce by GCC "backend" routines.

And why is this a problem, well through the years a number of GCC versions 
have had issues with processor and code optimization. You can find a few 
papers on file at some major university libraries and a couple on the 
internet. As an example you can find an articles on GCC versions and 
the 128/256-bit multi-precision math packages, stating the package is not 
being optimized correctly on some version of GCC. 

So, should GNAT use GCC backend or should GNAT bypass GCC "backend" and 
have its own "Middle and Back End" routines. For the issue of Ada 
optimization it seams that GNAT should bypass GCC. Because Ada contains 
two options for optimization one is for "Space" and "Time" which both could 
be handled initially in the "Middle end". Where the uncalled routines could 
be removed and then the remaining AST code could be optimize for Time.  
Then later in the binder ("gnatbind") could remove any dead code from 
precompiled Ada library packages, while linking that package, unlike most 
other linkers which just copy the dead code into the program. But in order 
to remove the dead code the binder ("gnatbind") would have to bypass calling 
GCC linkers and preform the link/editing itself while removing the dead code 
from the library packages. And course this removes the constant updating
of GNAT to every new version of GCC, which saves money and time.


As for 2020 and exceptions.

Taff S. Tucker stated in a number of speeches in the mid 1980s that he 
did not like the Ada exceptions he preferred the return code of the C 
procedure which is now apart of Ada 2012 function. So, it goes that Tucker 
may try to talk the ARG into removing exception data type altogether. 
Especially since 2020 might be his last chance to update Ada. And since 
most of the new Ada programmers are those moving from C they have little 
experience in using Ada exceptions so with the C like procedure aka Ada 
function they will not ever miss the power and performance of Ada exceptions 
and handlers.

And at the movement no one can say what changes will occur between adoption 
of 2012 and the adoption of 2020. But with the "return by type" change no
one want to bet on what will not be there.


These are three of a few reason why Ada has become "Obsolete" to most 
software shops and schools.



In <jm5qqp$n1g$1@dont-email.me>, "J-P. Rosen" <rosen@adalog.fr> writes:
>Le 11/04/2012 22:19, anon@att.net a �crit :
><anon header>This is a response to FUD spread as usual by anon, to warn
>people not to believe this nonsense </anon header>
>
>> A second problem is that every year the ARG is moving Ada toward a C like 
>> language. An example is in Ada 2012, is functions now can use "in out" 
>> within the parameter list
>As every C programmer knows, there are no in out parameters in C
>[...]
>
>> Which is classical C version of a procedure routine with the "return_type" 
>> being a error code. So, will the "Exceptions" and exception handler be 
>> next to be removed from Ada in 2020. That's a problem with existing Ada 
>> programmers, being that they may be forced to make 100s of re-writes 
>> to remove exceptions that no one want to do. And the ARG can not say 
>> for certain that exception will exist in Ada 2020 or after, until they 
>> vote on Ada 2020 RM sometime in 2020 or later.
>The ARG is very careful about incompatibilities, and these are
>introduced only when the benefits far outweighs the cost of
>incompatibility. As fas as exceptions are concerned, I challenge you to
>provide a single reference that the ARG ever considered removing them.
>
>> A third is the "Not null" clause that are use in routine's parameter list 
>> starting with Ada 2005.  That cause introduces inefficiency error checking 
>> at the beginning of the routine that can not be truly optimized.
>On the contrary, it replaces many checks in the body of the called
>subprogram by a single check at the call site.
>
>> There are others concepts that software division in companies like NASA 
>> or software shops do not like the direction Ada is going in because of 
>> the ARG.
>Please provide a reference to support that claim (other than your own
>rambling)
>
>-- 
>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