Re: Advice on selling Ada to a C shop

[anon@anon.org]

In <hvr1j8$f1k$1@speranza.aioe.org>, "Nasser M. Abbasi" <nma@12000.org> writes:
>On 6/22/2010 11:01 AM, anon@anon.org wrote:
>
>> In<774c25c4-3270-4ffb-ad19-366a0ab16659@i31g2000yqm.googlegroups.com>, Lucretia<Lucretia9000@yahoo.co.uk>  writes:
>>> Ask them what they don't like about C and developing in C (via a
>>> questionnaire if necessary), then show them how to do it in Ada,
>>> showing the benefits.
>>>
>>> This might help get the point across.
>>>
>>> Luke.
>>
>
>>
>> That might be true until Ada 2012! With C like structure being added
>> people will say why switch.
>>
>
>any link for someone to find what does "C like structure being added" 
>mean and how can that provide something that Ada record does't provide?
>
>--Nasser

For Ada, to pull ahead of the language fight, Ada 2012 needs to 
forget the conditional C-Like structures (see below) and define a 
true portable Window and Graphic packages in the RM.  These two 
packages should allow any Ada programmer to create a program 
that controls a set of Windows with Graphics without concerns of 
the OS or the processor used.

Like in the Window packages, a set of common routines to control and 
maintain a gui window regardless of the system used, But the actually 
routines would not be just a binder but would enhance the ability of 
the operation of the window.  Like using tasks or event handlers to 
monitor and control the function of the window. Such as monitoring 
when the windows is active and needs to monitor all assigned I/O 
devices as well as make changes to the windows when requested. Or in 
another case the routines could simply sleep as long as the windows 
is invisible and only wake-up to update the windows's screen buffer 
when screen output is requested. 

As for the graphics package.  Those routines and values are mostly 
commonly define with a few exceptions though out the different OSs 
and GPU cards that could be handle in an Ada graphics interface and 
binder package. Of course, the package routines might handle a series 
of commands which could free the main Ada partition to do other 
things.

These two packages and their sub-packages should of been introduced 
to Ada's RM a back in 2000 or earlier but the powers that be 
preferred unions and "oops" and now conditional structures instead.  
None of which truly aid Ada.  These ideas are slowly causes the 
death of Ada because without graphics and windows routine Ada is 
limited in it scope of partitions that people want.  The powers 
that maintain and updates Ada are not listening to the right 
programmers.  Some here in this newsgroup would like to see Ada 
include these two packages group, because it would allow a programmer 
to create a portable gui Ada project not found even in C.  This 
would be an advantage over C or MS .net system and give Ada 
the functionality of the graphics that in found in Java but with the 
performance of a true native language.



C like Structures: 

Unions are one thing, but non Ada conditional structures are another!

AT&T create C and the first C compiler then licensed the primary 
design to IBM, NCR, Univac (unisys), DEC, etc, as well as a number 
colleges and universities but no control or RM was given for that 
design.  So, each license holder created their own version of the 
language. A "put" in one system might be define as a "putch" in 
another. Also constants like "NULL" may be define as a "0x0" in one 
system and the next system could define the value as either upper or 
lower limit of a integer while others it a user definable constant.  
Also, even a logical statement may result in a true value for one 
system while being false in another. So, to solve some of these 
and others problems conditional structures were added to C instead 
of defining and enforcing a C RM.

But all full Ada compilers are required to follow the RM and any 
alteration of the Ada system must be defined and allowed in the 
RM. Like, the System.Machine_Code package is defined as optional.  
DEC preferred to use other languages like an assembler or other 
high level languages instead of providing the System.Machine_Code 
package. While IBM and SUN version of Ada mostly followed the Ada 
RM example design. And Adacore programmers using gcc kind of 
created their own version of this package. If one looks at the 
Ada RM 13.8 section for the System.Machine_Code package one will 
see that that all three ways this package is handle are legal.


Now, with the release of GNAT 2009, Adacore started including 
"Conditional Structures".

In GNAT 2009, the "If" conditional structure was added.

   <Variable> := (if ...  then ... else ... );

Not sure if you can use add the "elsif .... then"  clause.

This is too close to C like structures for any Ada purist to approve of.
It is better and more portable to have two or more packages instead.

An example of this type of structure come from Ada.Text_IO.adb line 568:
 
  Item :=
    (if not Is_Start_Of_Encoding (Character'Val (ch), File.WC_Method)
        then Character'Val (ch)
        else Get_Upper_Half_Char_Immed (Character'Val (ch), File));


The C version would be:

  /*
   * #define CharacterVal (c)  c    // definition is not needed 
   */

  Item = (!Is_Start_Of_Encoding (ch, File.WC_Method)
          ? ch
          : Get_Upper_Half_Char_Immed (ch, File)
         );

Does this improve coding. No! It only allows a small group of C coded 
routines to be ported directly to Ada code, instead of just using the 
"Interfaces.C.*" packages and the "pragma Import" or "pragma Export" 
statements. Why should any programmer spend their time in rewriting 
the code from one language to another, if the code works.  And if the 
code does not work then simply translating the code into Ada may not 
correct the problem, but trashing the bad C code and starting from 
scratch could. So, its better to just compile and use the C code if 
it works as a small external library routine. 

Also, if you ask, most programmers do not want to spend their time in 
transferring a C or any library like the vast Fortran libraries to Ada 
just to use that routine or library in Ada. They prefer write pure 
Ada and just link to the libraries or routine written in other 
languages when needed.