C is 'better' than Ada because...

C is 'better' than Ada because...

[Alan Brain]

The first real-world C program I did was in 1980. Since 1983 I've been trying to 
convince C hackers about the benefits of Ada. Those that actually were forced to do 
some real project in Ada were quickly converted. But mainly, no-one tried.

Trying to tell people about the benefits often leads to complete stonewalling. There 
has to be a logical reason for this - few programmers have low IQs.

I've finally become convinced that C really IS better than Ada, for the following 
reasons:


FOR THE PROGRAMMER

..Hacking away in C is fun, you can add trapdoors and trojan horses real easy

..You can write neat stuff like the following code fragments:

    #define BITCOUNT(x)      (((BX_(x)+(BX_(x)>>4)) & 0x0F0F0F0F) % 255)
    #define BX_(x)            ((x) - (((x)>>1)&0x77777777)  \
                                   - (((x)>>2)&0x33333333)  \
                                   - (((x)>>3)&0x11111111)
    p = BX_(n);

    n = ((n>>1)  & 0x55555555) | ((n<<1)  & 0xaaaaaaaa);
    n = ((n>>2)  & 0x33333333) | ((n<<2)  & 0xcccccccc);
    n = ((n>>4)  & 0x0f0f0f0f) | ((n<<4)  & 0xf0f0f0f0);
    n = ((n>>8)  & 0x00ff00ff) | ((n<<8)  & 0xff00ff00);
    n = ((n>>16) & 0x0000ffff) | ((n<<16) & 0xffff0000);

   which is difficult to understand, and makes you look really, really clever,
   even though it does something utterly trivial ( p is the number of bits in n,
   and n ends up with its bit order reversed )

..You'll always have a secure job, trying to make sense of other people's code
   after they've left

..You'll always have a secure job, as with well-written, terse, tight and
   efficient C YOU are the ONLY one who can easily understand your own code!

..You'll always have a secure job, as large C programs always have lots of bugs,
   and require oodles of maintenance

..Compiling is really easy - even when the stuff you're compiling is utter
   garbage, the compiler won't tell on you

..You can ignore most of your coding errors until quite late in the day - with
   any luck, until you've left the project


FOR THE SUPPLIER

..You can always find C hackers, and they're dirt cheap

..With C, you get the initial build done quick, cheap and dirty, and make a
   fortune over the next 10 years putting in new bugs while removing old ones.


FOR THE CUSTOMER

..Because programmers and suppliers tell you so.



Ada is worse than C because

..Only Anal-retentive weenies who mumble about Quality and Professionalism
   would get any fun out of Ada

..You'd get into the habit of writing stuff like

   with MACHINE_SPECIFIC;

   procedure COUNT_BITS_AND_REVERSE
     ( THE_WORD  : in out MACHINE_SPECIFIC.WORD_TYPE,
       THE_COUNT :    out MACHINE_SPECIFIC.BIT_COUNT_TYPE
     ) is

   declare

     package BIT_OPS renames MACHINE_SPECIFIC.BIT_OPERATIONS;

   begin

     THE_COUNT := BIT_OPS.BIT_COUNT_OF(THE_WORD);
     BIT_OPS.REVERSE_BIT_ORDER_OF(THE_WORD);

   exception
 
     when others => raise CODE_CORRUPTED_OR_HARDWARE_ERROR;

   end COUNT_BITS_AND_REVERSE;

   which any fool can easily understand, even though it does trap some of
   the errors caused by the over-running array bounds in the C you've had
   to PRAGMA INTERFACE to, soft errors, and hardware glitches.
   Not only that, it works on 16, 32, 64, 48 etc bit machines as well. so
   can't get lost of bucks writing different versions.
   And then the compiler barfs, and tells you what you've done wrong!

..You spend a long time looking for a job, as your code on the last project
   worked so well that the project completed on time, and you were no longer
   needed.

..You spend a long time looking for a job, as the maintenance effort needed
   consisted of 2 part-timers rather than the whole development team

..You spend a long time looking for a job, as no-one uses Ada

..Getting a Clean Compile of anything non-trivial is quite difficult.

..Your Ego takes a hammering by the compiler constantly showing you where
   you made mistakes. And if not the compiler, the Linker!


FOR A SUPPLIER

..Ada programmers are rare and expensive. You can't hire cheap graduate coolies.

..It costs more initially to make a system, and it takes longer. Much worse,
   there's almost no maintenance, so your only revenue is from the initial sale.


FOR A CUSTOMER

..Because the programmers and suppliers tell you so.


That's the bottom line, people. The only people who benefit from Ada are the
customers and users. The user riding on a 777 generally doesn't know that any
programming was involved, and the customers rely on advice from their suppliers.

Until we understand that, all arguments regarding the qualities of Ada are
irrelevant.     

Re: C is 'better' than Ada because...

[Ron Thompson]

< I snipped the post out for reasons of brevity, and
< to somewhat flame proof myself. You know, those 
< c programmers will think that I wrote that!

I concur with no comment.

rct

The opinion(s) above are mine and mine alone.

Re: C is 'better' than Ada because...

[Nasser Abbasi]

   From: Alan Brain <aebrain@dynamite.com.au>
   Newsgroups: comp.lang.ada,comp.lang.c
   Date: 19 Jun 1996 08:56:24 GMT

..snip..

   I've finally become convinced that C really IS better than Ada, 
   for the following reasons:

(good stuff removed...)


But i must admonish you in public for not mentioning one more good 
reason why C/C++ is better than Ada , see why for yourself, below is are 
simple programs to print an array. How simpler than this can you get? 
I want to print the first 10 elements in my array, but Ada will NOT allow me
to do even this simplest of tasks, the thing keeps raising some exception 
telling me I went over the boundary of my array (what a silly  execuse to 
stop my program from running! )

While with C/C++, I can go over the boundary of the array all I want, 
no hasle or fuss, and it does it all so silently too as expected, after 
all this is MY array ! I own this array ! It is MY computer !
and so I have all the right to traverse it as long as I want , and so 
a simple stright forward for loop always me to print as many elements 
in the array as I want, as expected.

Offcourse sometimes one just have to rememeber to throw in the NULL thing 
somewhere near where they want to halt the string array from going too 
far, but that is easy, just keep few extra NULLs around for saftey and all 
will be well. (offcourse you need to remember to have an extra space at 
the end for the NULL thing so it wont get mungled with the data itself, 
but what the heck, easy to do , and if one forgets, I am sure there 
will be a NULL somewhere in memeory (espcially if you have large 
amount of memeory installed) to stop the array from reaching the end 
of the memory board, so not to worry there.

Therefor one must conclude that coding in C/C++ is much simpler and gives 
the programmer the freedom to do what they want while Ada keeps getting 
its nose in our code telling us what we can and can't do. Freedom is what
it is all about.

========= The Ada program

with Ada.Text_Io; use Ada.Text_Io;
procedure Main is
 I: Integer :=0;
 Vec : array(1..5) of Integer;
begin
   for I in 1..10 loop
       Vec(I):=I ;
       Put_Line(" Current value is "& Integer'Image(Vec(I)));
   end loop;
end Main;

$main
 Current value is  1
 Current value is  2
 Current value is  3
 Current value is  4
 Current value is  5

raised CONSTRAINT_ERROR  <--- Yuck! Ada will not allow me to loop Any More !!
                              what a pain! Now I have to go change my code :(
                              

======= the C program

#include <iostream.h>
main()
{
int vec[5];
int i;

    for(i = 0 ; i < 10 ; i++ )
    {
       vec[i] = i;
       cout<< " current value is " << vec[i] << endl; 
    }

}

$CC test1.cc
$a.out
 current value is 0
 current value is 1
 current value is 2
 current value is 3
 current value is 4
 current value is 5   <--- Nice !! C/C++ allows me to the freedom to loop
 current value is 6        I dont have to change my code :) 
 current value is 7        
 current value is 8
 current value is 9


Nasser
-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application 
for Nucleic acid and protein sequence search and analysis. 
PE-Applied BioSystem division. email:  nasser@apldbio.com   
MSEE(control), MSCS, MSCE, FM(Fide Chess Master 2305 ELO  1.e4 !!)

Re: C is 'better' than Ada because...

[David Morton]

> 
> ======= the C program
> 
> #include <iostream.h>
> main()
> {
> int vec[5];
> int i;
> 
>     for(i = 0 ; i < 10 ; i++ )
>     {
>        vec[i] = i;
>        cout<< " current value is " << vec[i] << endl;
>     }
> 
> }
> 
> $CC test1.cc
> $a.out
>  current value is 0
>  current value is 1
>  current value is 2
>  current value is 3
>  current value is 4
>  current value is 5   <--- Nice !! C/C++ allows me to the freedom to loop
>  current value is 6        I dont have to change my code :)
>  current value is 7
>  current value is 8
>  current value is 9
> 
> Nasser
> --
> Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application
> for Nucleic acid and protein sequence search and analysis.
> PE-Applied BioSystem division. email:  nasser@apldbio.com
> MSEE(control), MSCS, MSCE, FM(Fide Chess Master 2305 ELO  1.e4 !!)


I get:

 current value is 0
 current value is 1
 current value is 2
 current value is 3
 current value is 4
 current value is 5
 current value is 6
 current value is 7
 current value is 8
 current value is 9
Segmentation fault


so that c code *will* have to be changed...
But I am curious why it did seg fault sooner?
(BTW, That's why I'm posting this back to comp.lang.c)
Can anyone tell me why this doesn't seg fault sooner?
OS is Linux 2.0, GNU g++







-- 
David Morton
 mailto:dmorton@jinx.sckans.edu    // If you use Netscape 2.0,
 205 College, Winfield, KS 67156   // you can click on the mailto: part
to reply!
                                   (HINT, HINT)  :)

Re: C is 'better' than Ada because...

[Robert Dewar]

 that c code *will* have to be changed...
But I am curious why it did seg fault sooner?
(BTW, That's why I'm posting this back to comp.lang.c)
Can anyone tell me why this doesn't seg fault sooner?
OS is Linux 2.0, GNU g++"

I have no idea why you expect a seg fault at any particular point. If
you get a seg fault at all, it is certaily *very* implementation
dependent where it will occur, since who knows how the compiler lays
out memory, for example, it may put critical data for interfacing with
the operating system right after your array so that much more interesting
things happen than a segfault, such as destruction of your system disk :-)

Re: C is 'better' than Ada because...

[The Deviant]

On 22 Jun 1996, Robert Dewar wrote:

> Date: 22 Jun 1996 20:20:19 -0400
> From: Robert Dewar <dewar@cs.nyu.edu>
> Newsgroups: comp.lang.c, comp.lang.ada
> Subject: Re: C is 'better' than Ada because...
>
>
>  that c code *will* have to be changed...
> But I am curious why it did seg fault sooner?
> (BTW, That's why I'm posting this back to comp.lang.c)
> Can anyone tell me why this doesn't seg fault sooner?
> OS is Linux 2.0, GNU g++"
>
> I have no idea why you expect a seg fault at any particular point. If
> you get a seg fault at all, it is certaily *very* implementation
> dependent where it will occur, since who knows how the compiler lays
> out memory, for example, it may put critical data for interfacing with
> the operating system right after your array so that much more interesting
> things happen than a segfault, such as destruction of your system disk :-)
>

But, the variable was initialized as

char blah[5];

which means it goes out of its bouts as soon as it tries to access
blah[5], and thats when SIGSEGV, by definition, should occur.

--Deviant

Re: C is 'better' than Ada because...

[Michael Feldman]

In article <Pine.LNX.3.92.960623122941.795A-100000@switch.sp.org>,
The Deviant  <deviant@sp.org> wrote:
>
>But, the variable was initialized as
>
>char blah[5];
>
>which means it goes out of its bouts as soon as it tries to access
>blah[5], and thats when SIGSEGV, by definition, should occur.

Ah, but one of the beauties of C is that (in general) it doesn;t do
any range checking. Depending on how it really allocated your data,
your program may, or may not, have gone out of your memory area,
so no segmentation fault was raised.

It's adventures like this that are _so_ challenging to the macho
programmer types who just couldn't stand the compiler do wimpy stuff
like put range checking in their code.

Even nicer is an intermittent bug that _sometimes_  raises the seg
fault, depending on just how far you rolled beyond the bounds of your
array.

I'd much prefer to write that code as

   A: array (1..5) of character;

   . . .

   for i in A'range loop
     do_something_with_A;
   end loop;

Mike Feldman

Re: C is 'better' than Ada because...

[John Winters]

In article <Pine.LNX.3.92.960623122941.795A-100000@switch.sp.org>,
The Deviant  <deviant@sp.org> wrote:
>On 22 Jun 1996, Robert Dewar wrote:
>
>> Date: 22 Jun 1996 20:20:19 -0400
>> From: Robert Dewar <dewar@cs.nyu.edu>
>> Newsgroups: comp.lang.c, comp.lang.ada
>> Subject: Re: C is 'better' than Ada because...
>>
>>
>>  that c code *will* have to be changed...
>> But I am curious why it did seg fault sooner?
>> (BTW, That's why I'm posting this back to comp.lang.c)
>> Can anyone tell me why this doesn't seg fault sooner?
>> OS is Linux 2.0, GNU g++"
>>
>> I have no idea why you expect a seg fault at any particular point. If
>> you get a seg fault at all, it is certaily *very* implementation
>> dependent where it will occur, since who knows how the compiler lays
>> out memory, for example, it may put critical data for interfacing with
>> the operating system right after your array so that much more interesting
>> things happen than a segfault, such as destruction of your system disk :-)
>>
>
>But, the variable was initialized as

was defined as

>char blah[5];
>
>which means it goes out of its bouts as soon as it tries to access
>blah[5], and thats when SIGSEGV, by definition, should occur.

The only occasion on which SIGSEGV is defined as occuring is on
an explicit call to raise().

John

-- 
John Winters.  Wallingford, Oxon, England.

Re: C is 'better' than Ada because...

[Robert Dewar]

"The Deviant" said

"But, the variable was initialized as

char blah[5];

which means it goes out of its bouts as soon as it tries to access
blah[5], and thats when SIGSEGV, by definition, should occur."

Most amusing, someone who thinks that C works the way Ada does, and that
sigsegv means an out of bounds subscript :-)

Sorry to disappoint, but C typically has no bounds checking. A sigsegv
means you wandered out of *the entire data area for your program*, not
out of a particular array you have defined.

So, I am afraid the "by definition" in your above note is very wrong. Perhaps
you would like to take a closer look at languages like Ada which do indeed
define that a runtime exception must occur in such circumstances!

Re: C is 'better' than Ada because...

[token%/etc/HOSTNAME]

The Deviant (deviant@sp.org) wrote:

: But, the variable was initialized as

: char blah[5];

: which means it goes out of its bouts as soon as it tries to access
: blah[5], and thats when SIGSEGV, by definition, should occur.

Would you please share your enlightenment concerning the correct definition
of when SIGSEGV should occur? I only know that it's completely architecture
and OS-dependant.
If the array lies in a memory-page/segment/whatever that is accessible and 
writeable by the program, there will be no violation fault instantly but 
only after the program has executed a bit further and the side effect of
the above operation is causing trouble.  SIGSEGV is a hardware-triggered
thing and not part of a language definition.

--
    Matthias `Token' Buelow    @ Home: token@altair.franken.de  (PGP avail.)
                               Campus: token@cip.informatik.uni-wuerzburg.de

Re: C is 'better' than Ada because...

[John Winters]

In article <31CC75C1.5BF2AF6A@jinx.sckans.edu>,
David Morton  <dmorton@jinx.sckans.edu> wrote:
>> 
>> ======= the C program
>> 
>> #include <iostream.h>
>> main()
>> {
>> int vec[5];
>> int i;
>> 
>>     for(i = 0 ; i < 10 ; i++ )
>>     {
>>        vec[i] = i;
>>        cout<< " current value is " << vec[i] << endl;
>>     }
>> 
>> }
>> 
>> $CC test1.cc
>> $a.out
>>  current value is 0
>>  current value is 1
>>  current value is 2
>>  current value is 3
>>  current value is 4
>>  current value is 5   <--- Nice !! C/C++ allows me to the freedom to loop
>>  current value is 6        I dont have to change my code :)
>>  current value is 7
>>  current value is 8
>>  current value is 9
>> 
>> Nasser
>> --
>> Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application
>> for Nucleic acid and protein sequence search and analysis.
>> PE-Applied BioSystem division. email:  nasser@apldbio.com
>> MSEE(control), MSCS, MSCE, FM(Fide Chess Master 2305 ELO  1.e4 !!)
>
>
>I get:
>
> current value is 0
> current value is 1
> current value is 2
> current value is 3
> current value is 4
> current value is 5
> current value is 6
> current value is 7
> current value is 8
> current value is 9
>Segmentation fault
>
>
>so that c code *will* have to be changed...
>But I am curious why it did seg fault sooner?
>(BTW, That's why I'm posting this back to comp.lang.c)
>Can anyone tell me why this doesn't seg fault sooner?
>OS is Linux 2.0, GNU g++

In the eyes of the C language, anything is possible here, but the probable
reason it seg faulted where it did is that you overwrote the bit of
the stack holding the return address from the routine.  When the routine
tried to return it instead shot off into the wild blue yonder.

The observant will have noticed that the sample code isn't written in
C anyway.

John

-- 
John Winters.  Wallingford, Oxon, England.

Re: C is 'better' than Ada because...

[David Morton]

> >OS is Linux 2.0, GNU g++

...
> The observant will have noticed that the sample code isn't written in
> C anyway.

Of course, the *really* observent may have noticed that I used
g++ to compile it...  ;)


-- 
David Morton
 mailto:dmorton@jinx.sckans.edu    // If you use Netscape 2.0,
 205 College, Winfield, KS 67156   // you can click on the mailto: part to reply!
                                   (HINT, HINT)  :)

Re: C is 'better' than Ada because...

[John Winters]

In article <31CD3E1A.57D547EC@jinx.sckans.edu>,
David Morton  <dmorton@jinx.sckans.edu> wrote:
>> >OS is Linux 2.0, GNU g++
>
>...
>> The observant will have noticed that the sample code isn't written in
>> C anyway.
>
>Of course, the *really* observent may have noticed that I used
>g++ to compile it...  ;)
>

And the *really, really* observant will have noticed that the sample
code was headed:

======= The C program

John
-- 
John Winters.  Wallingford, Oxon, England.

Re: C is 'better' than Ada because...

[David Morton]

John Winters wrote:
> 
> In article <31CD3E1A.57D547EC@jinx.sckans.edu>,
> David Morton  <dmorton@jinx.sckans.edu> wrote:
> >> >OS is Linux 2.0, GNU g++
> >
> >...
> >> The observant will have noticed that the sample code isn't written in
> >> C anyway.
> >
> >Of course, the *really* observent may have noticed that I used
> >g++ to compile it...  ;)
> >
> 
> And the *really, really* observant will have noticed that the sample
> code was headed:
> 
> ======= The C program
> 
> John
> --
> John Winters.  Wallingford, Oxon, England.

ah good one!!!  Good thing *I* didn't start this thread! ;)

I guess I don't fall under the *really, really* observant category... 
yet...  :)

-- 
David Morton
 mailto:dmorton@jinx.sckans.edu    // If you use Netscape 2.0,
 205 College, Winfield, KS 67156   // you can click on the mailto: part to reply!
                                   (HINT, HINT)  :)

Re: C is 'better' than Ada because...

[Lawrence Kirby]

In article <31CD3E1A.57D547EC@jinx.sckans.edu>
           dmorton@jinx.sckans.edu "David Morton" writes:

>> >OS is Linux 2.0, GNU g++
>
>...
>> The observant will have noticed that the sample code isn't written in
>> C anyway.
>
>Of course, the *really* observent may have noticed that I used
>g++ to compile it...  ;)

Which of course begs the question of why you used g++ to compile code
that was posted to comp.lang.c and comp.lang.ada.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: ) OH NO "...begs the question..."

[Ralph Silverman]

Lawrence Kirby (fred@genesis.demon.co.uk) wrote:
: In article <31CD3E1A.57D547EC@jinx.sckans.edu>
:            dmorton@jinx.sckans.edu "David Morton" writes:

: >> >OS is Linux 2.0, GNU g++
: >
: >...
: >> The observant will have noticed that the sample code isn't written in
: >> C anyway.
: >
: >Of course, the *really* observent may have noticed that I used
: >g++ to compile it...  ;)

: Which of course begs the question of why you used g++ to compile code
: that was posted to comp.lang.c and comp.lang.ada.

: -- 
: -----------------------------------------
: Lawrence Kirby | fred@genesis.demon.co.uk
: Wilts, England | 70734.126@compuserve.com
: -----------------------------------------

--
*************begin r.s. response****************

	'beg the question'
	a flaw in argument...
	whereby the conclusion is assumed.

	the intellectual illiteracy instanced
	in
		the posting cited above
	(whereby this old form is abused
	 in a recently popular manner),
	should have no place here!

*************end r.s. response******************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: ) OH NO "...begs the question..."

[Bill Wendling]

Ralph Silverman inexplicably wrote:
} *************begin r.s. response****************

} 	'beg the question'
} 	a flaw in argument...
} 	whereby the conclusion is assumed.

} 	the intellectual illiteracy instanced
} 	in
} 		the posting cited above
} 	(whereby this old form is abused
} 	 in a recently popular manner),
} 	should have no place here!

} *************end r.s. response******************
} Ralph Silverman

Ralph, could you repost the above in some recognizable language?

--
Bill Wendling            bwendlin@fgi.net 
GCS/M/S d s-:+ a? C++++$ UL++>++++ P+++>+++++ L+++>+++++ E--- W-- N++ !o
!K w--- O M-- !V PS+++@ PE- Y !PGP t+++(*) 5-- X- R++ tv--- b+++ DI++++
!D G+ e++>+++++ h(++) !r !y+

Re: C is 'better' than Ada because...

[Nasser Abbasi]

   From: joeuser@satcom.whit.org (joeuser)
   Newsgroups: comp.lang.ada
   Date: 27 Jun 1996 01:19:55 GMT

   Was this to be a spoof?  

   Why would one want to read past the limits of ones array?  Who knows what 
   ^^^
   might be in that area of memory?  Chances are, it is the next thing you 
   declared.  Then again, maybe not, depending just where in memory this
   array  is located.  

Why? it seems the answer is obviouse. Becuase humans make mistakes. a 
programmer can use the wrong arrray range to loop. It is not like they 
would do it intnentionaly. 

In Ada it will be cought, in plain C/C++ it would not. (some
said that some C/C++ compiler do range checking). In Ada it is hard to use
the wrong array range to start with becuase you say A'Range, and even if you
do, the run-time will tell you if you did.


   Next: If you are using an array that changes sizes frequently, perhaps you 
   should use some other data structure.  Foregoing that, at least declare
   your array dynamically.

this is beside the point of the example to show that C/C++ did not do
range checking. What does declaring an array dynamically has to do with
range checking?


   Finally: If you are still insistant on declaring a static array, at least 
   do it this way.
   .
   .        optinal --> integer
   .                       v
   Size_Of_Array : constant := 5;
   .
   .
   .
   Vec: array(1..Size_Of_Array) of integer;
   .
   .
   .
   end Main;


Yes, sure nice, I think we know that , But Again, this is beside the point 
of the example. 

   I still cannot think of any reason to even attempt to write values beyond 
   the constraints of the array and into unknown memory.  I really would like 
   to hear any REAL arguments as to why one would desire, and especially 
   NEED, to do this.

a REAL argument is that programmers make mistakes and it is easier in
C/C++ to do such mistakes and not know about them becuase the 
compiler/run-time do not tell you about them. in C/C++ you might spend
 hours looking for such a bug especially if the program is large, 
involving many arrays or matrices, and they are being passed around 
different functions to process, etc.. I've seen programs in C that were
using wrong array range calculations, yet have been running with no 
apparent problems, but someday would crash, or behave funny, 
and one would just start the program again, and in few days it might 
crash again, etc..   Offcourse there are super C/C++ programmers who
never make mistakes such as using the wrong array size, and then this
discussion do not apply to them.



   In article <nhk9wzyjn3.fsf@paralysys>, nasser@apldbio.com says...
   >   I've finally become convinced that C really IS better than Ada, 
   >   for the following reasons:
   >

   snip..

   >
   >========= The Ada program
   >
   >with Ada.Text_Io; use Ada.Text_Io;
   >procedure Main is
   > I: Integer :=0;
   > Vec : array(1..5) of Integer;
   >begin
   >   for I in 1..10 loop
   >       Vec(I):=I ;
   >       Put_Line(" Current value is "& Integer'Image(Vec(I)));
   >   end loop;
   >end Main;
   >

   Output omitted...

   >
   >======= the C program
   >
   >#include <iostream.h>
   >main()
   >{
   >int vec[5];
   >int i;
   >
   >    for(i = 0 ; i < 10 ; i++ )
   >    {
   >       vec[i] = i;
   >       cout<< " current value is " << vec[i] << endl; 
   >    }
   >
   >}
   >

   Output omitted...

   BTW.  I think a validated compiler will catch that constraint error at 
   compile time.  

Dont know about that. I used the C++ compiler on my SOlaris 2.5 station and
it let me loop outside the array boundary. If better C/C++ compilers will
catch this type of error, that is fine, that's one more hole in C/C++ we've 
patched up untill the next one shows up.


Nasser
-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application 
for Nucleic acid and protein sequence search and analysis. 
PE-Applied BioSystem division. email:  nasser@apldbio.com   
MSEE(control), MSCS, MSCE, FM(Fide Chess Master 1.e4 !!   1-0 )

Re: C is 'better' than Ada because...

[Nasser Abbasi]

   From: jont@t-cubed.demon.co.uk (Jon Taylor)

   I have programmed in both C and Ada for a number of years, and your
   article is misleading in many respects.  You can write bad code in 
   Ada just as easily as bad code in C.   I worked on the
   primary flight computer for the 777 project, and the software was
   a mess - and it was written in Ada.

   Sure, C lets you do silly things and doesn't pick up on things
   like array bounds and overflows, but you can get similar problems
   in any language.  Your examples were unfair, in that you picked
   a horrendous C example, but picked a sensible Ada comparison.

   I suspect the reasons Ada is not more popular than it rightly
   deserves are (amongst others) :-

   a) There is a large body of skilled C programmers, who would
      rather keep their skills in that language.  Better the devil
      you know.

   b) Validated Ada compilers are not cheap.  Using gnat is just not
      good enought for a commercial system.

   c) There is no perceived benefit to making the change to Ada. 

   Even the DoD no longer mandates the use of Ada for defence projects.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^

Is this really true? The DoD policy changed on Ada? when did this happen?


nasser
-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application 
for Nucleic acid and protein sequence search and analysis. 
PE-Applied BioSystem division. email:  nasser@apldbio.com   
MSEE(control), MSCS, MSCE, FM(Fide Chess Master 2305 ELO  1.e4 !!)

Re: C is 'better' than Ada because...

[Fergus Henderson]

>   From: jont@t-cubed.demon.co.uk (Jon Taylor)
>
>   I suspect the reasons Ada is not more popular than it rightly
>   deserves are (amongst others) :-
>
>   b) Validated Ada compilers are not cheap.  Using gnat is just not
>      good enought for a commercial system.

If an unvalidated C compiler is good enough for a commercial system,
why wouldn't an unvalidated Ada compiler be good enough?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: C is 'better' than Ada because...

[Robert Dewar]

Fergus said:

   >   From: jont@t-cubed.demon.co.uk (Jon Taylor)
   >
   >   I suspect the reasons Ada is not more popular than it rightly
   >   deserves are (amongst others) :-
   >
   >   b) Validated Ada compilers are not cheap.  Using gnat is just not
   >      good enought for a commercial system.
   
   If an unvalidated C compiler is good enough for a commercial system,
   why wouldn't an unvalidated Ada compiler be good enough?

This is a bit misleading. First there are many validated C compilers (you
could have made your point by saying C++, but not C, which has a formal
validation procedure comparable to that of Ada, though perhaps the test
suite is not quite so comprehensive).

Second, the issue of whether GNAT is or is not "good enought" for a
commercial system is not particuarly dependent on validation anyway.
There are validated GNAT compilers (you can obtain a formally validated
version of GNAT, complete with a copy of the validation certificate from
Ada Core Technologies for the SGI Indy, Indigo-2, or Onyx, and we expect
to validate several new targets in the near future).

However, getting a validation certificate does not guarantee usability for
a given purpose. For example, if you want to use Ada 95, you may be quite
disappointed that a validated Ada 95 compiler may have NO Ada 95 features,
none at all! (see the Thomson home page for a discussion of this issue).

On the other hand, many commercial systems are successfully using GNAT
today, using both validated and unvalidated versions of the system. As
for price ("Validated Ada compilers are not cheap"), the cost for example
in the SGI case of their GNAT-based Ada 95 development system is essentially
identical to the cost of equivalent C++ tools.

Robert Dewar
Ada Core Technologies

Re: C is 'better' than Ada because...

[Fergus Henderson]

dewar@cs.nyu.edu (Robert Dewar) writes:

>Fergus said:
>
>   >   From: jont@t-cubed.demon.co.uk (Jon Taylor)
>   >
>   >   I suspect the reasons Ada is not more popular than it rightly
>   >   deserves are (amongst others) :-
>   >
>   >   b) Validated Ada compilers are not cheap.  Using gnat is just not
>   >      good enought for a commercial system.
>   
>   If an unvalidated C compiler is good enough for a commercial system,
>   why wouldn't an unvalidated Ada compiler be good enough?
>
>This is a bit misleading. First there are many validated C compilers (you
>could have made your point by saying C++, but not C, which has a formal
>validation procedure comparable to that of Ada, though perhaps the test
>suite is not quite so comprehensive).

So how cheap are *validated* C compilers?  Are they significantly
cheaper than validated Ada compilers?  And of the people who choose
C instead of Ada because validated Ada compilers are too expensive,
how many of them use validated C compilers and how many use unvalidated
C compilers?

>Second, the issue of whether GNAT is or is not "good enought" for a
>commercial system is not particuarly dependent on validation anyway.

Yes, that's my point.  For many purposes, validation is not important,
and if e.g. Borland or Microsoft C/C++ is OK, then an unvalidated Ada
compiler ought to be OK too.  It seems to me that Ada and C/C++ are
being held to different standards here.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <4r19k9$b05@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

> dewar@cs.nyu.edu (Robert Dewar) writes:
> ...
> >Second, the issue of whether GNAT is or is not "good enought" for a
> >commercial system is not particuarly dependent on validation anyway.
> 
> Yes, that's my point.  For many purposes, validation is not important,
> and if e.g. Borland or Microsoft C/C++ is OK, then an unvalidated Ada
> compiler ought to be OK too.

Absolutely.  Spot on point.


>  It seems to me that Ada and C/C++ are being held to different
      ^^^^^
> standards here.

That's because they are....

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

C is better than Ada, because it doesn't pretend it knows more about
programming than I do, and doesn't prevent me from doing those things that are
upon rare occasion necessary.  Programming is C is like shaving with a razor;
as long as I know what I'm doing, there's no problem.   Programming in Ada is
like using a shaver; it 'protects' the incompetent and is no help to the
experts.

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Robert Dewar]

Kevin said

"C is better than Ada, because it doesn't pretend it knows more about
programming than I do, and doesn't prevent me from doing those things that are
upon rare occasion necessary.  Programming is C is like shaving with a razor;
as long as I know what I'm doing, there's no problem.   Programming in Ada is
like using a shaver; it 'protects' the incompetent and is no help to the
experts."

This surely can't be a real comment, it must be made up by some anti-C
fanatic :-)

Re: C is 'better' than Ada because...

[Fergus Henderson]

kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes:

>C is better than Ada, because it doesn't pretend it knows more about
>programming than I do, and doesn't prevent me from doing those things that are
>upon rare occasion necessary.

This is a very persistent rumour, but I have yet to see any evidence for it.
As far as I am aware, it's quite possible to do all those things you can
do in C in Ada too.

>Programming is C is like shaving with a razor;
>as long as I know what I'm doing, there's no problem.   Programming in Ada is
>like using a shaver; it 'protects' the incompetent and is no help to the
>experts.

There's a fundamental difference between software engineering and shaving:
shaving is a solitary activity, but software engineering is generally not.
If you were shaving *my* face, I'd rather you not use a razor!

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: C is 'better' than Ada because...

[Mike Roske]

Fergus Henderson wrote:
> 
> kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes:
> 
> >C is better than Ada, because it doesn't pretend it knows more about
> >programming than I do, and doesn't prevent me from doing those things that are
> >upon rare occasion necessary.
> 
> This is a very persistent rumour, but I have yet to see any evidence for it.
> As far as I am aware, it's quite possible to do all those things you can
> do in C in Ada too.
> 

Ok, then here's a challenge.  Point me at any compress/decompress
package (a la Zip) written in Ada.  I've been searching the world and
come up empty.  Even here in the comp.lang.ada group I was referred to C
language implementations.

Thanks in advance,
Mike

P.S.  Someone who knows how to use the razor can give you a 2-day shave
using it.  Someone who only knows how to use a shaver (barely) might hit
the right location.  The key is in knowing how to build quality
software, not in using a particular language...

-- 
*-------------------------------------------------------*
* Michael Roske
* Sanders, A Lockheed Martin Company
* mroske@mailgw.sanders.lockheed.com
* (603) 885-9240
*-------------------------------------------------------*
* "I'd rather be flying RC..."                     
*-------------------------------------------------------*

Re: C is 'better' than Ada because...

[Robert Dewar]

Mike said

"Ok, then here's a challenge.  Point me at any compress/decompress
package (a la Zip) written in Ada.  I've been searching the world and
come up empty.  Even here in the comp.lang.ada group I was referred to C
language implementations."

Maybe you should reread the earlier posts in this thread. The claim was
that you can program such utilities in Ada, not that someone has done so.
Indeed Ada is clearly expressive enough, as are many languages, for the
claim that you can program anything in Ada to be trivially true.

This does not mean that all possible tasks have already been programmed
in Ada, or that it is appropriate to do so. In fact as you may remember
from my earlier reaction to the discussion of compression algorithgms,
it seems idiotic to me to program such a utility in Ada when there are
perfectly usable reliable utilities already existing that you could use.

Re: C is 'better' than Ada because...

[Ken Garlington]

Mike Roske wrote:
> 
> > As far as I am aware, it's quite possible to do all those things you can
> > do in C in Ada too.
> >
> 
> Ok, then here's a challenge.  Point me at any compress/decompress
> package (a la Zip) written in Ada.

Actually, I wrote an Ada implementation of Huffman encoding some years ago,
just for the fun of it. I'd give it to you, but I never used it for anything real
and so I didn't keep it.

If you have a "C" implementation of Zip, you can
either (1) just interface it with your Ada code, so long as you don't mind maintaining
the C fragment, or (2) take the C implementation, extract the algorithm, and
implement it in Ada. Both should be straightforward to do.

I think you'll find that, if there's already plenty of good implementations of
an algorithm in C, FORTRAN, etc., there's not a lot of motivation to recode them.
I suspect most Ada programmers want to solve problems that haven't already been
solved to death. :)

> *-------------------------------------------------------*
> * Michael Roske
> * Sanders, A Lockheed Martin Company
> * mroske@mailgw.sanders.lockheed.com
> * (603) 885-9240
> *-------------------------------------------------------*
> * "I'd rather be flying RC..."
> *-------------------------------------------------------*

-- 
LMTAS - "Our Brand Means Quality"

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On 30 Jun 1996 06:33:29 GMT, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote:
>If you were shaving *my* face, I'd rather you not use a razor!

How many barbers use an electric shaver on their customers?

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Ian Ward]

In article 57288085@netline-fddi.jpl.nasa.gov, kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes:
>On 30 Jun 1996 06:33:29 GMT, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote:
>>If you were shaving *my* face, I'd rather you not use a razor!
>
>How many barbers use an electric shaver on their customers?
>
>-- 
>#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
> _
>Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
>Per the FCA, this email address may not be added to any commercial mail list

Not very many, but most use electric shears.
In fact, as a coincidence I shave with a cut throat
razor, made by Solingen of Germany. I do this, like
all things, because it meets my requirements, it gives
the best shave I think, when I have time to use it,
and it is cheap (very.) Ok, to be fair here, it cost
forty quid to buy new, and fifteen quid to buy the
leather strap. It now though, has extremely low
maintenance costs, and no waste. 

The right tool for the right job, and as such I
recognise that it has faults though, so conversely,
rarely, but when I am in a rush for a meeting
say, I use a Remington microscreen or twin blade Boots
throwaway, because, even though it is not as close as
a blade (despite the advertisements,) it is is close
enough, and I look less stupid with a bit of a five
o'clock shadow in the evening, than I would with a
huge hole in my face, due to a rushed shave. Jan Wuyts
will confirm this, he having seen me with one or two
disastrous cuts, because I may sneeze, or even just
took the thing for granted and stopped concentrating.

Best regards, Kevin, but I bet you wear a seat belt
when you drive a car. 

---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be

Re: C is 'better' than Ada because...

[Peter Amey]

All this talk about skilled programmers and being over-protected by Ada 
reminds me of something that was drummed into me during my aviating 
days.  I was taught:

"The superior pilot uses his superior judgement to avoid situations that 
would require his superior skill"

I use Ada precisely because it avoids the need constantly to demonstrate
my superior skill :-)

Peter

Re: C is 'better' than Ada because...

[Robert Dewar]

Peter Amey said

"All this talk about skilled programmers and being over-protected by Ada
reminds me of something that was drummed into me during my aviating
days.  I was taught:

"The superior pilot uses his superior judgement to avoid situations that
would require his superior skill"

I use Ada precisely because it avoids the need constantly to demonstrate
my superior skill :-)

Peter"

Robert responds

Well there are some posts on CLA that certainly make it worth while to
continue reading it :-)

Peter, that's a really nice quote. I emailed you but my mailer does not
understand your reply address. Anyway, I would like to ask if I can
use that quote in its entirety on future occasions (with proper
attribution of course -- incidentally does anyone know the origin
of the referenced quotation?)

Thanks Peter for brightening up the day :-)

Re: C is 'better' than Ada because...

[James A. Squire]

John F. Bode wrote:

> What is considered C's greatest asset is also its greatest failing for
> developing large, robust systems: it assumes that you, the programmer,
> know what you are doing at all times.  That's a bad assumption to make
> for a lot of us (me included).
>
> John F. Bode
> representing nobody but myself...

Au Contraire, may I add myself as one represented by your assessment
here.  Bravo on your insightful rebuttal.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: C is 'better' than Ada because...

[Oliver Kellogg]

Electing at random one of many issues, I generally find string
processing in C less tedious than Ada83. One of the rare occasions
where the beauty of Ada83 strings showed was this:

function Replicate (C : Character; Times : Positive) return String is
   Buffer : String(1..Times) := (others => C);
begin
   return Buffer;
end Replicate;

-- just my $0.02 worth...
-- Oliver

Re: C is 'better' than Ada because...

[Oliver Kellogg]

I had written:

> function Replicate (C : Character; Times : Positive) return String is
>    Buffer : String(1..Times) := (others => C);
> begin
>    return Buffer;
> end Replicate;

On second thought,

	#include <string.h>
	char *replicate (char c, int times)
	{
	  char *buffer = (char *) malloc (times);
	  return (char *) memset (buffer, c, times);
	}

is not that much less elegant either :-)

Re: C is 'better' than Ada because...

[Fraser Wilson]

okellogg@cube.net (Oliver Kellogg) writes:

>	#include <string.h>
>	char *replicate (char c, int times)
>	{
>	  char *buffer = (char *) malloc (times);
>	  return (char *) memset (buffer, c, times);
>	}

>is not that much less elegant either :-)

Well, that's a matter of taste.  I prefer the Ada version -- the C one
has a lot of really ugly low-level stuff.  I mean, typecasts?  It looks
as though you're trying to do something naughty (but that's a way of
life in C, isn't it?).

Two advantages that the Ada code has are:
	1. it didn't require the caller to clean up allocated memory, and
	2. you were able to write it first time without introducing a
	   rather nasty (and common) bug that appears in the C code.

Fraser.
--
    ____ Fraser Wilson          | email: fraser@cs.mu.oz.au     __o
    \  / The more I learn of    | voice: +61 3 9287 9193      _-\<,_
     \/  C++, the more I like   | fax:   +61 3 9348 1184     (_)/ (_)
           --- Ada 95 ---       | www:   http://www.cs.mu.oz.au/~fraser/

Re: C is 'better' than Ada because...

[Fergus Henderson]

fraser@mundook.cs.mu.OZ.AU (Fraser Wilson) writes:

>okellogg@cube.net (Oliver Kellogg) writes:
>
>>	#include <string.h>
>>	char *replicate (char c, int times)
>>	{
>>	  char *buffer = (char *) malloc (times);
>>	  return (char *) memset (buffer, c, times);
>>	}
>
>>is not that much less elegant either :-)
>
>Well, that's a matter of taste.  I prefer the Ada version -- the C one
>has a lot of really ugly low-level stuff.  I mean, typecasts?

Neither of the typecasts in the above example are necessary.
It could be rewritten as

	#include <string.h>
	#include <stdlib.h>
	char *replicate (char c, int times)
	{
	  return memset (malloc (times), c, times);
	}

However, the fact that the Ada version works whereas
the C version is buggy is a pretty strong argument...
the C version won't look nearly as elegant once
you've fixed the two bugs.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: C is 'better' than Ada because...

[Keith Thompson]

In <4sgeme$r32@salyko.cube.net> okellogg@cube.net (Oliver Kellogg) writes:
> I had written:
> 
> > function Replicate (C : Character; Times : Positive) return String is
> >    Buffer : String(1..Times) := (others => C);
> > begin
> >    return Buffer;
> > end Replicate;
> 
> On second thought,
> 
> 	#include <string.h>
> 	char *replicate (char c, int times)
> 	{
> 	  char *buffer = (char *) malloc (times);
> 	  return (char *) memset (buffer, c, times);
> 	}
> 
> is not that much less elegant either :-)

Elegant or not, it's probably incorrect (depending on what you're trying
to do with the result).  Your replicate function returns a pointer to
an array of characters, but it's not a string unless you add a trailing
nul character.

Storage management is also a potential problem, which is handled
automatically in Ada.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
"As the most participatory form of mass speech yet developed, the Internet
deserves the highest protection from government intrusion." -- ACLU v. Reno

Re: C is 'better' than Ada because...

[Robert Dewar]

Oliver said

"Electing at random one of many issues, I generally find string
processing in C less tedious than Ada83. One of the rare occasions
where the beauty of Ada83 strings showed was this:"

Are you including automatic storage reclamation -- that seems rather hard
work in C, and is of course built in to Unbounded_String handling?

Re: C is 'better' than Ada because...

[James A. Squire]

Mike Roske wrote:

> > What is considered C's greatest asset is also its greatest failing for
> > developing large, robust systems: it assumes that you, the programmer,
> > know what you are doing at all times.  That's a bad assumption to make
> > for a lot of us (me included).
>
> I have to disagree a little bit here.  I don't believe Ada FORCES you to
> write good, clean, safe code.  It just makes certain bad things more
> difficult to accomplish.

I see no disagreement between this statement and the one it is
responding to, not even a little bit.  No one SAID Ada FORCES you to
write good, clean, safe code.

> Having had the experience of guiding (shepherding? ;-)  ) several 'C' code
> writers into writing more structured software, I can tell you that it is just
 as
> easy to write bad, dirty, dangerous code in Ada.

And this statement of yours contradicts the above statement of yours,
where you said, "It (Ada) just makes certain bad things more difficult
to accomplish."

If you are attempting (by using words like "certain bad things") to
minimize this, you have a long way to go to make your case.  It is not
at all obvious that in a strongly typed language such as Ada it is "just
as easy to write bad" code as it is in not-strongly typed language like
C.  Strong-typing alone means less opportunities to screw up.  And
that's just one area.  What about piggy-backing case parts of switch
statements because someone forgot to put in the "break;" statements?
What about the lack of bounded enumeration types, especially the crucial
Boolean type and the corresponding "!=0" default boolean condition,
which kicks in because you forgot to specify "==" instead of "="?  What
about the inability to specify input-only scalar parameters (or can you
declare a parameter to be "const" now?)?  What about the lack of any
boundary checking at all?  What about runaway pointers?

These and probably a number of other flaws the Ada language simply does
not have.  I do not include leaving garbage collection up the user which
both Ada83 and C have (though Ada95 does improve upon this with
Ada.Finalization).  Furthermore, both Ada83 and Ada95 still have goto's,
so that too is a wash.

You might be tempted to bring up the "use" clause.  Think again.  C
operates with a default "use" clause on everything.  Where the Ada
programmer has to explicitly put in a use clause for each desired
package in order to secretly use anything in those packages (which he
blindly and erroneously assumes is an iron-clad guarantee), the C
programmer has to explicitly use the word "static" in a module to
prevent any other module from "extern"-ing the given data object.  As
much trouble as "use" causes in Ada, it's still better than what C has.

All you have shown is that in Ada it is still POSSIBLE to write bad
code.  Bravo.  Take two opaque pointers out of petty cash.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: C is 'better' than Ada because...

[Nasser Abbasi]

   From: "James A. Squire" <m193884@CSEHP3.MDC.COM>

   Strong-typing alone means less opportunities to screw up.

good point.

   And that's just one area.  What about piggy-backing case parts of switch
   statements because someone forgot to put in the "break;" statements?
   What about the lack of bounded enumeration types, especially the crucial
   Boolean type and the corresponding "!=0" default boolean condition,
   which kicks in because you forgot to specify "==" instead of "="?  

good points.

   What about the inability to specify input-only scalar parameters (or 
   can you declare a parameter to be "const" now?)?  

I am not sure I understand this. Do you mean like doing enumeration IO 
in Ada ?

   What about the lack of any  boundary checking at all?  
                               ^^^^^^^^^^^^^^^^^^^^^^^^^
   What about runaway pointers?

But runaway pointers is what makes C/C++ programming so much
more challenging :)

James make good points ofccourse, but I think the view that C++ 
programmers would have is that some of the above could be fixed 
by using classes instead of the primitive language data types. At least 
to the point of boundary checking. As an example, one would use 
an array class instantiated to the correct type and the size of the
array, where this class would throw an exception (or do an assert) if 
the index is out of bounds. SOmething like this:

----------------------------------------------
template< class type, int dimension>
class array
{
 ....
 type operator[] ( int index)
 {
   if( index >= dimension || index < 0 )
      throw ... some object as the exception

   // or  assert ( index < dimension && index >=0); 

   // all clear now , index is within range, get the index data
   return data[index];
 }
 

 private:
   type data[dimention];
};
--------------------------------------------

and one would then create objects of this class as

array<int,10> a;  // now a is array of int 0..9
array<chat,100> b; // array of chars 0..99
..
now writing this
   int i = a[11];   // should throw an exception

So, in C++ it seems that one can say, if there is something not
right in the core langauge, one can use the core language to fix
this problem, as the example above show, one uses C++ to fix
the fact that C++ do not have boundary range checking.

The problem I see with this is that this addes a layer of
software between the application/usr and the core langauge, in
the above example, this layer is the array class software, so
would would then use this class to make arrays instead of using
the array construct avaliable in the core language.

Adding this layer requires support. Who will write these classes?
are they going to be part of the standard libraries, are they
going to be well documented and tested? who will do that? Are
they going tobe on each platform ? etc..

In Ada, array boundary checking is "build" into the langauge,
it is part of the language definition, and what execptions are
raised is also defined, so I think this makes it feel safer. 

But if those C++ classes are become part of the
standard library (as STL template classes would be), then there 
should be less risk in using them I would guess. But now it seems there
are many C++ class libraries out there, and code written using one
class library one be hard to port to another. Example, If I write
my code using Rouge Wave class library, or MFC or etc.. and 
later on I decided I do not want to use that class library any 
more, I would be stuck. In Ada, on each platform, the same array
boundary is done the same way, since it is in the language, not
in some higher library layer.

Nasser  


-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application 
for Nucleic acid and protein sequence search and analysis. 
Perkin Elmer - Applied BioSystem division. email:  nasser@apldbio.com   
MSEE(control), MSCS, MSCE, FM (Fide Chess Master).

Re: C is 'better' than Ada because...

[Mark A Biggar]

In article <nhafx022lu.fsf@paralysys> nasser@apldbio.com (Nasser Abbasi) writes:
>   What about the lack of any  boundary checking at all?  
>James make good points ofccourse, but I think the view that C++ 
>programmers would have is that some of the above could be fixed 
>by using classes instead of the primitive language data types. At least 
>to the point of boundary checking. As an example, one would use 
>an array class instantiated to the correct type and the size of the
>array, where this class would throw an exception (or do an assert) if 
>the index is out of bounds. SOmething like this:
>----------------------------------------------
>template< class type, int dimension>
>class array
>{
> ....
> type operator[] ( int index)
> {
>   if( index >= dimension || index < 0 )
>      throw ... some object as the exception
>   // or  assert ( index < dimension && index >=0); 
>   // all clear now , index is within range, get the index data
>   return data[index];
> }
> private:
>   type data[dimention];
>};
>--------------------------------------------
>and one would then create objects of this class as
>array<int,10> a;  // now a is array of int 0..9
>array<chat,100> b; // array of chars 0..99
>..
>now writing this
>   int i = a[11];   // should throw an exception
>So, in C++ it seems that one can say, if there is something not
>right in the core langauge, one can use the core language to fix
>this problem, as the example above show, one uses C++ to fix
>the fact that C++ do not have boundary range checking.
>The problem I see with this is that this addes a layer of
>software between the application/usr and the core langauge, in
>the above example, this layer is the array class software, so
>would would then use this class to make arrays instead of using
>the array construct avaliable in the core language.

In addition the above code make it almost impossible to optimize
out unnecessary checks.  The empirical evidence is that only about
10% of array bounds checks are really necessary, assuming that you
can declare index variables that are limited in range to the 
array bounds, but you can't so that either in C (you can in C++,
but that adds yet another layer of possible redundant checks
that you can't easily optimize away.)

--
Mark Biggar
mab@wdl.lmco.com

Re: C is 'better' than Ada because...

[Laurent Guerby]

Oliver> Electing at random one of many issues, I generally find string
Oliver> processing in C less tedious than Ada83. One of the rare occasions
Oliver> where the beauty of Ada83 strings showed was this:
Oliver> 
Oliver> function Replicate (C : Character; Times : Positive) return String is
Oliver>    Buffer : String(1..Times) := (others => C);
Oliver> begin
Oliver>    return Buffer;
Oliver> end Replicate;

   What about the very simple

   Times * Character 

   See RM95-A.4.3(105). Note that a Replicate function is language
defined in Ada 95, and that, according to the context, the given
expression can be a String (Ada 83), a Bounded_String (a la Pascal,
max length given) or an Unbounded_String (Ada 95, possibly "infinite"
length and "garbage collected").

   See also the good article by Richard Rielhe on String handling in
Ada 95 in a recent JOOP issue. I cannot seriously believe that someone
saying that C String handling is more elegant than Ada one is not
trolling ;-).

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: C is 'better' than Ada because...

[David Emery]

 function Replicate (C : Character; Times : Positive) return String is
    Buffer : String(1..Times) := (others => C);
 begin
    return Buffer;
 end Replicate;

Of course, if the number of characters you need is known at compile-time,
there's always the aggregrate
   string'(1..times_constant => c)
I can't remember if times_constant HAS to be static or not...
            dave

Re: C is 'better' than Ada because...

[James A. Squire]

Nasser Abbasi wrote:

>    What about the inability to specify input-only scalar parameters (or
>    can you declare a parameter to be "const" now?)?
>
> I am not sure I understand this. Do you mean like doing enumeration IO
> in Ada ?

No.  I was confused.  I withdraw that one.  I was thinking of something
else.  Actually, it smells like there is a hole there somewhere, since
in C the caller has some control over specifying what we in Ada call the
"mode" of the conceptual parameter (via the & operator), whereas in Ada
this is completely specified by the callee.  What I thought of was the
warning they give in a Motif training class about the following kind of
code:

        n = 0;
        XtSetArg(arglist[n++], XmNx, 500);
        XtSetArg(arglist[n++}, XmNy, 200);
        XtSetValues(widget, arglist, n);

They said this was a no-no because n gets incremented twice on each
XtSetArg.  What I completely forgot is that XtSetArg is a macro, not a
function.  Sorry....

>
>    What about the lack of any  boundary checking at all?
>                                ^^^^^^^^^^^^^^^^^^^^^^^^^
>    What about runaway pointers?
>
> But runaway pointers is what makes C/C++ programming so much
> more challenging :)
>
> James make good points ofccourse, but I think the view that C++
> programmers would have is that some of the above could be fixed
> by using classes instead of the primitive language data types. At least

Could be.  I'm not familiar with C++ yet.  Of course, C++ doesn't
prevent you from falling back on the old C way of doing things, and C
was the language being compared to Ada.  My point was that these are
things you literally cannot do even if you wanted in Ada, or as is the
case (I now realize) with boundary checking, at least in Ada you have to
go out of your way to open things up (pragma suppress) whereas in C you
have to go out of your way to shut things down.

As you point out, in Ada boundary checking is built in to the language,
which means you have to explicitly turn it off, or else you will get
compilation errors or constraint errors.  In C++ you would have to
implement it yourself and then promise to use only that which you
created to do things, or else you can violate boundaries without
complaint.

We're pretty much in agreement.  I just wanted to further clarify my
point.  Thank you in any event for the support.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: C is 'better' than Ada because...

[James A. Squire]

Oliver Kellogg wrote:

> Electing at random one of many issues, I generally find string
> processing in C less tedious than Ada83.

Certainly.  However, I still feel safer with strings in Ada.
                                  ^^^^^

My hope is that Ada.Strings.Bounded will turn out to ease the tedium of
strings in Ada95.  But tedium I can adjust to; runaway string pointers
and string functions that make me nervous (e.g., I can NEVER remember
which is the copy-to parameter and which is copy-from parameter in
strcpy) are another matter.
--
James Squire
mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace                      http://www.mdc.com/
Opinions expressed here are my own and NOT my company's
"Nice shark...pretty shark..."
        -- Londo, "The Gathering"

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On Fri, 5 Jul 1996 09:29:56 +0100, Peter Amey <pna@erlang.praxis.co.uk> wrote:
>"The superior pilot uses his superior judgement to avoid situations that 
>would require his superior skill"
>
>I use Ada precisely because it avoids the need constantly to demonstrate
>my superior skill :-)

I do the same in C.  The problem is that Ada won't *let* you use your superior
skill, i.e., nothing is gained by it.  For someone who knows what they're
doing, it's just as easy to write good, clean, safe code in C (or assembly, or
*any* language) as it is in Ada.

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada ... NOT!!

[Hugh Dunne]

kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) wrote:
>On Fri, 5 Jul 1996 09:29:56 +0100, Peter Amey <pna@erlang.praxis.co.uk> wrote:
>>"The superior pilot uses his superior judgement to avoid situations that 
>>would require his superior skill"
[I love that quote!]
>>
>>I use Ada precisely because it avoids the need constantly to demonstrate
>>my superior skill :-)
>
>I do the same in C.  The problem is that Ada won't *let* you use your superior
>skill, i.e., nothing is gained by it.  For someone who knows what they're
>doing, it's just as easy to write good, clean, safe code in C (or assembly, or
>*any* language) as it is in Ada.

There are always ways of getting around Ada restrictions - using
unchecked conversion, pragma interface etc. The point is that you can't
do it by accident - you have to take explicit steps to short-circuit
the safeguards, which hopefully will make you stop and think about
what you are doing.

Re the second point: IN THEORY it's possible to write highly virtuous
code in any language and crappy code in Ada (and I've seen plenty of
the latter.) In practice, any help which the compiler offers you to
avoid mistakes should be gratefully accepted! I get very impatient with
people who complain about the compiler taking away their freedom to be
creative etc. This is a prima donna attitude. If I'm sitting on a plane
controlled by a software fly-by-wire system, I want it to be solidly
engineered by competent developers who use all appropriate tools, not
"created" by software "wizards"!
-- 
--------------- http://www.vjf.com/PUBLIC/86/27186.html ---------------
Hugh Dunne/Logica UK Ltd/Stephenson House/75 Hampstead Rd/London NW1 2PL
The above are strictly my own personal opinions  | dunneh@lhd.logica.com
and in no way reflect the opinions of Logica.    | +44 171 446-1608

Re: C is 'better' than Ada ... NOT!!

[Frank Manning]

>kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) wrote:
>>
>> I do the same in C.  The problem is that Ada won't *let* you use your superior
>> skill, i.e., nothing is gained by it.  For someone who knows what they're
>> doing, it's just as easy to write good, clean, safe code in C (or assembly, or
>> *any* language) as it is in Ada.
>
> There are always ways of getting around Ada restrictions
>                 [...]
>                                            I get very impatient with
> people who complain about the compiler taking away their freedom to be
> creative etc. This is a prima donna attitude. If I'm sitting on a plane
> controlled by a software fly-by-wire system, I want it to be solidly
> engineered by competent developers who use all appropriate tools, not
> "created" by software "wizards"!

Ah -- this reminds me of another old saying in aviation -- "There are old
pilots, and there are bold pilots, but there are no old, bold pilots."

In article <4rqhgj$1l1g@info4.rus.uni-stuttgart.de>
ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) writes:

> me too. I am curious how many more in CLA fly (and especially aerobatics)

I do, although no aerobatics (well, except once...)

-- Frank Manning

Re: C is 'better' than Ada ... NOT!!

[Kevin D. Quitt]

On 8 Jul 1996 12:03:00 GMT, Hugh Dunne <dunneh@lhd.logica.com> wrote:
>If I'm sitting on a plane
>controlled by a software fly-by-wire system, I want it to be solidly
>engineered by competent developers who use all appropriate tools, not
>"created" by software "wizards"!

I agree, but being the latter doesn't preclude the former.  There *is* too
much art and not enough science in software. "'Computer Science' is to
'Science' as 'Plumbing' is to 'Hydrodynamics'".

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[John F. Bode]

In article <31E4DC46.794BDF32@mailgw.sanders.lockheed.com> Mike Roske,
mroske@mailgw.sanders.lockheed.com writes:
>I have to disagree a little bit here.  I don't believe Ada FORCES you to
>write good, clean, safe code.  It just makes certain bad things more
>difficult to accomplish.  Having had the experience of guiding
>(shepherding? ;-)  ) several 'C' code writers into writing more
>structured software, I can tell you that it is just as easy to write
>bad, dirty, dangerous code in Ada.  And we didn't really *know* it was
>dirty and dangerous until the testing phase.  It met all of the Ada
>guidelines and STILL corrupted memory (bad pointer allocation).
>

True: bad code can be written in any language (I'm living proof of that).
 I guess "forces" was too strong a word; maybe "strongly encourages?"  It
*is* a lot harder to shoot yourself in the foot with Ada than  it is with
C, though.

C was never designed to write *large* systems; reliance on text-based
#include files and inability to nest procedures alone is testimony to
that.  It is possible to write really big software with C, but it the
hassle curve rises exponentially as the size of the system increases. 
Just to carry the aviation analogy to ridiculous extremes, it's like
trying to build a 747 with a Popular Mechanics 20-piece socket set; the
basic tools are there, but they're not enough by themselves.  You wind up
spending all your time building the tools to build the plane, rather than
building the plane itself, and there is always the danger that somebody
gets one of the tools wrong and the whole thing falls apart on takeoff
because somebody fastened a 3/4" bolt with a 7/8" nut.

Since Ada was designed from the outset to solve large-scale system
problems, it provides the necessary tools, but it takes a while to learn
to use them effectively.  I reject the notion that "it's just as easy to
do it in C" -- I've used both, and I will swear on a stack of Gideon
Bibles that no, it is *not* as easy to do it in C.  Not if you expect the
goddamn thing to *work* when you're finished.

FWIW, Ada is not the be-all and end-all, either.  Nor is C++.  Neither
make it very straightforward to manage huge programs, and true code
reusability is still a pipe dream IMO.  

John F. Bode
still working on an appropriate .sig...

Re: C is 'better' than Ada because...

[Sandy McPherson]

John F. Bode wrote:
> It *is* a lot harder to shoot yourself in the foot with Ada than it is
> with C, though.

However, when something does go wrong, your whole leg is likely to
disappear!

> 
> C was never designed to write *large* systems; reliance on text-based
> #include files and inability to nest procedures alone is testimony to
> that.
>
>..........
>  
> Since Ada was designed from the outset to solve large-scale system
> problems, it provides the necessary tools, but it takes a while to learn
> to use them effectively.  I reject the notion that "it's just as easy to
> do it in C" -- I've used both, and I will swear on a stack of Gideon
> Bibles that no, it is *not* as easy to do it in C.  Not if you expect the
> goddamn thing to *work* when you're finished.
> 

> John F. Bode
> still working on an appropriate .sig...

It depends upon which type of large system you wish to implement. Ever
tried to write an operating system, or a configurable toolkit, which needs
to use callbacks, in Ada? Yeuch!!! A Motif based GUI? Head for the hills!
In these areas C or C++ wins every time. Whether this is a problem of Ada
as a language is disputable, as these types of systems are traditionally
the stamping ground of C anyway; however as a great believer in making life
easy for myself, I would stick to C/C++ in these areas.

If on the other hand you have a bare chip and need to write a complex
embedded system, (and you have a GOOD Ada compiler), then Ada is probably a
better starting point, because there are so many fetures built into the
language which you have to do manually when coding good C.

The main advantage that C has over Ada is that the compilers are generally
very reliable (because of their small size) and produce efficient machine
code. If you have good PA standards and the correct tools (lint, QAC,
Purify, to name but a few) you can achieve very good results with C,
sometimes better than with Ada. 

The main advantage Ada has over C is its well defined source architecture
and easily employed data abstraction facilities and the tools which are
built into the APSE; these have to be built into a good C program, but a
plonker will bugger this up in Ada as well. Tasking looks like a good idea,
but the implementations can be weak; in fact most spacecraft control
systems I have seen implement their own tasking mechanisms, especially
where they have to respond to hardware interrupts.

Ada should be better than C for most applications, but has certain
weaknesses. Let's see what Ada 95 brings, or shouldn't we all be looking at
Eiffel?

-- 
Sandy McPherson	MBCS CEng.	tel: 	+31 71 565 4288 (w)
ESTEC/WAS
P.O. Box 299
NL-2200AG Noordwijk

Re: C is 'better' than Ada because...

[Robert Dewar]

Sandy said

"It depends upon which type of large system you wish to implement. Ever
tried to write an operating system, or a configurable toolkit, which needs
to use callbacks, in Ada? Yeuch!!!"

It is perfectly easy to use callbacks in Ada, I suspect Sandy meant Ada 83
in the above statement, which leads me to think that presumably a lot of
or all his comments were about Ada 83.

Re: C is 'better' than Ada because...

[Theodore E. Dennison]

Robert Dewar wrote:
> 
> Sandy said
> 
> "It depends upon which type of large system you wish to implement. Ever
> tried to write an operating system, or a configurable toolkit, which needs
> to use callbacks, in Ada? Yeuch!!!"
> 
> It is perfectly easy to use callbacks in Ada, I suspect Sandy meant Ada 83
> in the above statement, which leads me to think that presumably a lot of
> or all his comments were about Ada 83.

I have never had any trouble using callbacks in Ada 83, either. We do that 
every day here. I'm completely stumped as to what language Sandy is talking 
about.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: C is 'better' than Ada because...

[Theodore E. Dennison]

Sandy McPherson wrote:
> 
> It depends upon which type of large system you wish to implement. Ever
> tried to write an operating system, or a configurable toolkit, which needs
> to use callbacks, in Ada? Yeuch!!! A Motif based GUI? Head for the hills!
> In these areas C or C++ wins every time. Whether this is a problem of Ada

I have done a couple Motif based GUI's in Ada. It wasn't tough at all, and 
ended up being WAY more reliable than a C equivalent. Plus, Ada's tasking
allows your program to easily do other things besides just being a slave
to the GUI. Ada would be my FIRST choice for implementing Motif GUIs.

(And I wasn't that near the hills at the time).

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: C is 'better' than Ada because...

[Ken Garlington]

Sandy McPherson wrote:
> 
> It depends upon which type of large system you wish to implement. Ever
> tried to write an operating system, or a configurable toolkit, which needs
> to use callbacks, in Ada?

Yes - in fact, there are multiple RTOSs on my project written in Ada.

> A Motif based GUI?

I have personally written nultiple Ada tools on DEC that use Motif. Callbacks
work just fine, and they are quite straightforward to implement. Ada 95, with
an explicit access-to-subprogram feature, probably makes this equally simple
on all platforms.

> Whether this is a problem of Ada
> as a language is disputable

Absolutely.

> If on the other hand you have a bare chip and need to write a complex
> embedded system, (and you have a GOOD Ada compiler), then Ada is probably a
> better starting point, because there are so many fetures built into the
> language which you have to do manually when coding good C.

Since I haven't written much C for embedded systems, I couldn't say.

> The main advantage that C has over Ada is that the compilers are generally
> very reliable (because of their small size)

Possibly - I have seen reliable Ada compilers and not-so-reliable ones.

> and produce efficient machine code.

Why is this an advantage of C over Ada? Ada certainly produces efficient
machine code, given a good compiler. In fact, there are examples of Ada
outperforming C with regard to efficiency.

> Tasking looks like a good idea,
> but the implementations can be weak; in fact most spacecraft control
> systems I have seen implement their own tasking mechanisms, especially
> where they have to respond to hardware interrupts.

This has been my experience as well. However, protected records may
be a better mechanism for some of those cases where tasking wasn't appropriate.

-- 
LMTAS - "Our Brand Means Quality"

Re: C is 'better' than Ada because...

[Michael Feldman]

In article <31EF7E48.5ABE@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:

[quoting an earlier poster]

>> The main advantage that C has over Ada is that the compilers are generally
>> very reliable (because of their small size)

[and responding]

>Possibly - I have seen reliable Ada compilers and not-so-reliable ones.

Anything you'll get these days will be at least as reliable as the
typical C compiler. There is absdolutely no reason why they shouldn;t be.
Sure, there were pretty rotten Ada compilers 10 years ago, but there
have been rotten C compilers too.
>
>> and produce efficient machine code.
>
>Why is this an advantage of C over Ada? Ada certainly produces efficient
>machine code, given a good compiler. In fact, there are examples of Ada
>outperforming C with regard to efficiency.

Indeed, there are documented cases of Ada outperforming hand-coded
assembler, too, on embedded processors. See 

http://www.acm.org/sigada/education 

and click on "success stories".

Algorithm for algorithm, Ada compilers will typically do as well as
C compilers on the machine code. Sometimes a little better, sometimes
worse, but generally in the same ballpark. The (once partly true)
impression of clunky Ada compilers producing rotten code dies hard.
>
>> Tasking looks like a good idea,
>> but the implementations can be weak; in fact most spacecraft control
>> systems I have seen implement their own tasking mechanisms, especially
>> where they have to respond to hardware interrupts.
>
>This has been my experience as well. However, protected records may
>be a better mechanism for some of those cases where tasking wasn't 
>appropriate.

There's also a vicious-circle effect - if system designers avoid the
tasking implementation and go down to the OS or the bare iron instead,
what incentive do compiler builders have to improve the tasking?
The best way to get well-optimized tasking is to _use it_.
Compiler (and runtime) builders set their priorities according to
perceived customer need. Wouldn;t you do the same?

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) 
http://www.seas.gwu.edu/faculty/mfeldman
------------------------------------------------------------------------
       Pork is all that money the government gives the other guys.
------------------------------------------------------------------------
WWW: http://lglwww.epfl.ch/Ada/ or http://info.acm.org/sigada/education
------------------------------------------------------------------------

Re: C is 'better' than Ada because...

[Alfonso Urdaneta]

I happen to like C better, becuase it more mature but
you can write bad code in any language...

Re: C is 'better' than Ada because...

[Robert Dewar]

Alfonso said

"I happen to like C better, becuase it more mature but
you can write bad code in any language..."

I have great news for you, there are languages that are far more mature 
than C, so you should switch immediately. Examples are Algol-60, COBOL
and Fortran.

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On 21 Jul 1996 20:30:59 -0400, dewar@cs.nyu.edu (Robert Dewar) wrote:

>Alfonso said
>
>"I happen to like C better, becuase it more mature but
>you can write bad code in any language..."
>
>I have great news for you, there are languages that are far more mature 
>than C, so you should switch immediately. Examples are Algol-60, COBOL
>and Fortran.
>

A friend of mine is working on Object-oriented COBOL.  The truly terrifying
thing is that it's not a joke.

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Robert Dewar]

Kevin said

"A friend of mine is working on Object-oriented COBOL.  The truly terrifying
thing is that it's not a joke."


:-)

so, I was right, you don't like COBOL either, and apparently you 
particularly don't like Object-oriented COBOL. I guess you know nothing
about either, and the unknown terrifies you.

(my smiley above is because I predicted your reaction to COBOL before
reading this post!)

In fact the design of object oriented COBOL, the preliminary work on which
Ken Belcher worked [Ken was one of the team of three, including me that
did he original Realia COBOL implementation], is really quite interesting.
Definitely worth understanding if you are interested in language design
and seeing what is going on in some other areas.

Re: C is 'better' than Ada because...

[Richard Riehle]

On Mon, 22 Jul 1996, Kevin D. Quitt wrote:

> A friend of mine is working on Object-oriented COBOL.  The truly terrifying
> thing is that it's not a joke.

  I wonder why this is so terrifying.  There is more COBOL in place
  throughout the business data processing community than any other
  language.  Though certain aspects of COBOL, such as its early
  dependency on global data (the Data Division) increased the difficulty
  of maintenance, and the rules of the "go to" could, and did, lead to
  pathological control structures, modern COBOL is evolving to take
  advantage of what we have learned over the past decade or so, while
  preserving what was good about the original language design.

  One of the most absurd things that MIS directors have done in the
  past several years is try to convert their financial systems to C++.
  It is far safer, and far more productive, to transition those early
  COBOL applications to OOCOBOL than to move to something as inherently
  unreliable as the C family of languages, including C++.

  Of course, the ideal solution would be for these MIS managers to
  effect that transition with Ada, but such perspicacity is probably
  too much too expect.  So OOCOBOL is at least a better alternative
  than C++.


  Richard Riehle

Re: C is 'better' than Ada because...

[Darrin Smith]

In article <Pine.GSO.3.92.960726122347.25896E-100000@nunic.nu.edu>, 
rriehle@nunic.nu.edu says...

[snip]

>  One of the most absurd things that MIS directors have done in the
>  past several years is try to convert their financial systems to C++.
>  It is far safer, and far more productive, to transition those early
>  COBOL applications to OOCOBOL than to move to something as inherently
>  unreliable as the C family of languages, including C++.


How long have you been coding in C++?  Although I might agree that it is more 
logical to go from COBOL to OOCOBOL (especially if your current development 
team knows COBOL), your comment about the C language is totally asinine.

What makes C, or any other language unreliable anyway?  It is not the language, 
but rather those who code it that makes the end product a reliable one.  If 
anything, with C++ (as well as other OO languages) if you know your base 
classes work, then you're well on your way to developing MORE reliable 
software.

[snip]
>  Of course, the ideal solution would be for these MIS managers to
>  effect that transition with Ada, but such perspicacity is probably
>  too much too expect.  So OOCOBOL is at least a better alternative
>  than C++.

Why Ada?  Who has ever proven it to be better than COBOL for typical business 
apps?

Darrin Smith

Re: C is 'better' than Ada because...

[Fergus Henderson]

fignet05.darrins@eds.com (Darrin Smith) writes:

>What makes C, or any other language unreliable anyway?

The large number of things that the C standard defines to have
"undefined behaviour" make C less reliable, especially when combined
with compilers that by default do a relatively very low amount of
static checking.  The relatively low-level nature of the code
(in comparison to many other languages) and specifically
the use of manual memory management also contribute to a greater
number of errors.  For example, many of the memory management errors
that can occur in string manipulation errors in C simply can't occur
in many other languages, including COBOL.

(Overheard in one of our computer labs:
	Student A:  What causes segmentation violations?
	Student B:  Programming in C.
;-)

That said, C has many advantageous qualities, and with careful
programming, good tools, and careful testing, talented programmers can
produce reliable programs in C.  Still, if reliability was critical,
C would not be my first choice.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: C is 'better' than Ada because...

[Jerry van Dijk]

Darrin Smith (fignet05.darrins@eds.com) wrote:
: In article <Pine.GSO.3.92.960726122347.25896E-100000@nunic.nu.edu>, 
: rriehle@nunic.nu.edu says...

: >  One of the most absurd things that MIS directors have done in the
: >  past several years is try to convert their financial systems to C++.

: How long have you been coding in C++?  Although I might agree that it is more 
: logical to go from COBOL to OOCOBOL (especially if your current development 
: team knows COBOL), your comment about the C language is totally asinine.


Really ? On what experience are you refering too ? I'm not aware of *any*
major financial system written in C or C++. But I know plenty written in
either PL/1 or COBOL.


-- 
-----------------------------------------------------------------------
--  Jerry van Dijk       --   e-mail: jerry@jvdsys.nextjk.stuyts.nl  --
--  Banking Consultant   --              Member Team-Ada             -- 
--  Ordina Finance BV    --    Located at Haarlem, The Netherlands   --

Re: C is 'better' than Ada because...

[Kirk Bradley]

Well..Oracle Financials is all in C


In article <DvGr4I.4C@jvdsys.nextjk.stuyts.nl>,
jerry@jvdsys.nextjk.stuyts.nl (Jerry van Dijk) wrote:

> Darrin Smith (fignet05.darrins@eds.com) wrote:
> : In article <Pine.GSO.3.92.960726122347.25896E-100000@nunic.nu.edu>, 
> : rriehle@nunic.nu.edu says...
> 
> : >  One of the most absurd things that MIS directors have done in the
> : >  past several years is try to convert their financial systems to C++.
> 
> : How long have you been coding in C++?  Although I might agree that it
is more 
> : logical to go from COBOL to OOCOBOL (especially if your current development 
> : team knows COBOL), your comment about the C language is totally asinine.
> 
> 
> Really ? On what experience are you refering too ? I'm not aware of *any*
> major financial system written in C or C++. But I know plenty written in
> either PL/1 or COBOL.
> 
> 
> -- 
> -----------------------------------------------------------------------
> --  Jerry van Dijk       --   e-mail: jerry@jvdsys.nextjk.stuyts.nl  --
> --  Banking Consultant   --              Member Team-Ada             -- 
> --  Ordina Finance BV    --    Located at Haarlem, The Netherlands   --

Re: C is 'better' than Ada because...

[Richard Riehle]

Darrin Smith (fignet05.darrins@eds.com) wrote:
  In article <Pine.GSO.3.92.960726122347.25896E-100000@nunic.nu.edu>,
  rriehle@nunic.nu.edu says...

>  >  One of the most absurd things that MIS directors have done in the
>  >  past several years is try to convert their financial systems to C++.

> How long have you been coding in C++?  Although I might agree that it is more
> logical to go from COBOL to OOCOBOL (especially if your current development
> team knows COBOL), your comment about the C language is totally asinine.

  Darrin,

  I welcome your differing point-of-view but would prefer that
  we not resort to pejoratives in discussing it, OK.

  My view, with regard to the C family of languages, is not something
  at which I have arrived so lightly as you might assume.  As only one
  of many technical points, I regard any language which depends on
  pointer arithmetic for the creation of non-trivial programs to be
  potentially dangerous.  Call me asinine if you will, but I suspect I
  am not alone in this view.  C and C++ do encourage such practices
  as part of the development process.  I could cite other examples of
  dangerous aspects of C++, including the truly bizarred exception
  handling model, but brevity dictates otherwise.

  Thank you for agreeing with regarding the benefits of OO COBOL over
  C++.  Of course, if an organization were to decide to totally
  abandon their use of COBOL, Ada would certainly be a more suitable
  choice than C++. Ada 95 actually includes a model (in one of its
  annexes) for interpoperability with legacy COBOL code, and an
  information systems annex that makes it easy for a COBOL programmer
  to use data types and data editing features that are closer to
  those of COBOL.

  C++ and C are probably fine for certain classes of problems, but they
  are certainly archaic when compared to the progress being made in
  the world of programming languages. And I do not refer only to Ada in
  that last sentence.  Eiffel also comes to mind as a preferred
  alternative to C++.

  Today's C++ software is tomorrow's legacy system.

  Richard Riehle

Re: C is 'better' than Ada because...

[Craig Franck]

Richard Riehle <rriehle@nunic.nu.edu> wrote:

>  C++ and C are probably fine for certain classes of problems, but they
>  are certainly archaic when compared to the progress being made in
>  the world of programming languages. And I do not refer only to Ada in
>  that last sentence.  Eiffel also comes to mind as a preferred
>  alternative to C++.


I agree with that, if you include PC programming as "a certain class of 
problems". Most PC OS's are written in C/C++. It makes sense that
applications would then be coded in C/C++ as well. Pascal has more 
support than Ada does in this area. I don't know of a vendor supporting
those platforms in Ada as well as is done with C/C++. So you go with
C/C++ due to the quality of the impementation, not the language.

I would also like to point out that technical superiority is not always
a good indicator of success. Even if Ada is "better" than C++ that does
not indicate it will replace it in area's where C/C++ is now domanant.
Realize it's much easier get a C compiler up and running for an embedded
system that it is an Ada compiler. To even call it an Ada compiler it 
must pass a validation suite. 

The problem information systems managers have is today you must
incorporate PC users. Why develope a schizophrenic additute of doing
one with the domant tool (C/C++) and the other with Ada? I can see keeping
working in COBOL, but if you were to switch, switch to C++. 

I don't think AT&T is going to start coding thier switching systems 
in Ada just because it a better language, either.


>  Today's C++ software is tomorrow's legacy system.
>

Doubtfull, very doubtfull

-- 

Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[Richard Riehle]

On 10 Aug 1996, Craig Franck wrote:

> I agree with that, if you include PC programming as "a certain class of
> problems". Most PC OS's are written in C/C++. It makes sense that
> applications would then be coded in C/C++ as well.

  No. Sorry. xin l^oi. Does not make sense. This statement reflects a
  fundamental lack of understanding of selecting the right tool for
  the right job. It also fails to recognize the importance of abstraction.

  For example, for mathematical problem solving, there is a plethora
  of better alternatives to C++.  For database solutions, C++ is far
  behind the many available alternatives.

  The criteria selecting a programming language should include the
  question, "How well does the language map to the problems I am
  trying to solve?"  By problems, I mean the application problem, not
  the computer problem.  If I am trying to solve a problem which
  involves massive multi-dimensional matrices of with run-time
  indeterminate magnitude, I would be best served by a language
  and its associated libraries which map most directly to that
  problem.

  I regard C++ as just too flaky, for example, to be used for
  safety-critical software. If it is OK to reboot when something
  goes wrong, go ahead and use C++. If lives depend on the quality
  of your software the selection of C++ is just short of insane.
  Just my opinion, but not an opinion arrived at lightly.

> Pascal has more
> support than Ada does in this area. I don't know of a vendor supporting
> those platforms in Ada as well as is done with C/C++. So you go with
> C/C++ due to the quality of the impementation, not the language.

  For desktop systems such as Windows 95 and NT, this is probably not
  far off. Support, even for MS-DOS, has not historically been as
  strong in Ada as it has in other languages. This is changing, and
  software publishers are escalating their support for tools and libraries
  to make Ada more attractive on the desktop.

  On the other hand, for safety-sensitive embedded systems, this is not
  true.  Ada is clearly a superior alternative to C++ when it comes to
  safe software, even though C++ continues to be used in this application
  domain.  The original problem of poor management of the Ada policy by
  the Department of Defense is difficult to overcome, but it is important
  that we do overcome it in the interest of public safety.

> I would also like to point out that technical superiority is not always
> a good indicator of success.

  No argument there.

  [snip, snip ]

> system that it is an Ada compiler. To even call it an Ada compiler it
> must pass a validation suite.

  Exactly!  Though passing validation does not ensure total quality, it
  is a first step in that direction.

> The problem information systems managers have is today you must
> incorporate PC users. Why develope a schizophrenic additute of doing
> one with the domant tool (C/C++) and the other with Ada? I can see keeping
> working in COBOL, but if you were to switch, switch to C++.

  Au contraire. Ada is unique in its direct support for legacy COBOL
  systems through a set of data types, Annexes, and other pre-defined
  packages.  In fact, no contemporary object-oriented programming
  language is as hospitable to COBOL as Ada. Ada is a perfect fit for
  the Information Systems Manager seeking solutions for modernizing
  exisiting COBOL-based software.

> I don't think AT&T is going to start coding thier switching systems
> in Ada just because it a better language, either.

  I am manifestly unimpressed by this argument.

> >  Today's C++ software is tomorrow's legacy system.
> >
>
> Doubtfull, very doubtfull

  After all is said, we can be assured that 100 years from now, our
  successors, whatever they might be called, will regard our efforts
  at designing software languages with the same high esteem we reserve
  for mathematicians in the time of Charlemagne.

  Richard Riehle

Re: C is 'better' than Ada because...

[Craig Franck]

Richard Riehle <rriehle@nunic.nu.edu> wrote:
>On 10 Aug 1996, Craig Franck wrote:
>
>> I agree with that, if you include PC programming as "a certain class of
>> problems". Most PC OS's are written in C/C++. It makes sense that
>> applications would then be coded in C/C++ as well.
>
>  No. Sorry. xin l^oi. Does not make sense. This statement reflects a
>  fundamental lack of understanding of selecting the right tool for
>  the right job. It also fails to recognize the importance of abstraction.
>
>  For example, for mathematical problem solving, there is a plethora
>  of better alternatives to C++.  For database solutions, C++ is far
>  behind the many available alternatives.

I agree that you are much better off using a database language for
database programming, no arguement there. You are also correct that if
other languages are available that are more suitable for the problem 
at hand, you should use them. There are trivial reasons for programming
both OS and applications; the strings might be represented in the
same fashion and the subroutine linkage would be the same. Also heavy
UNIX use forms a bias as well; it's helpfull to read the source code for
a system function to gain understanding of what the OS is up to. The 
ability to change and recompile the kernel is nice, but from the
point of view of real world software, this kind of fooling around
probably does more harm than good! I feel that the level of support 
for C/C++ on Windows and UNIX platforms is the best of any language.
Yes, you can program in Ada on a UNIX platform but I would point 
out that the compiler is written in C. If C/C++ are your primary 
languages for writting system software, when it's time to write
an application that might seen like the best language to use.
This is a bias on my part that, though I can not defend it, I 
find myself falling victim to time and time again. Like when I'm
writing : how many OSs or compilers are written in Ada? And not as
an acedemic exercise to prove it is possible, but in actual use?
 
>  The criteria selecting a programming language should include the
>  question, "How well does the language map to the problems I am
>  trying to solve?"  By problems, I mean the application problem, not
>  the computer problem.  If I am trying to solve a problem which
>  involves massive multi-dimensional matrices of with run-time
>  indeterminate magnitude, I would be best served by a language
>  and its associated libraries which map most directly to that
>  problem.
>
>  I regard C++ as just too flaky, for example, to be used for
>  safety-critical software. If it is OK to reboot when something
>  goes wrong, go ahead and use C++. If lives depend on the quality
>  of your software the selection of C++ is just short of insane.
>  Just my opinion, but not an opinion arrived at lightly.

Well alot of the code for the telephone switching system is written 
in C/C++. The system did become unstable do to (how ironic!) a poorly coded
switch statement back in 1990, but on the whole I don't think there
is much rebooting going on of the switching systems mainframes. If
I were to ride on the space shuttle, I would be concerned with how
well the software was written and tested, not what language it
was written in. Though some languages lend themselves to hard to 
catch problems and many subtle distinctions that take a while to
master. 
>> Pascal has more
>> support than Ada does in this area. I don't know of a vendor supporting
>> those platforms in Ada as well as is done with C/C++. So you go with
>> C/C++ due to the quality of the impementation, not the language.
>
>  For desktop systems such as Windows 95 and NT, this is probably not
>  far off. Support, even for MS-DOS, has not historically been as
>  strong in Ada as it has in other languages. This is changing, and
>  software publishers are escalating their support for tools and libraries
>  to make Ada more attractive on the desktop.
>
>  On the other hand, for safety-sensitive embedded systems, this is not
>  true.  Ada is clearly a superior alternative to C++ when it comes to
>  safe software, even though C++ continues to be used in this application
>  domain.  The original problem of poor management of the Ada policy by
>  the Department of Defense is difficult to overcome, but it is important
>  that we do overcome it in the interest of public safety.

Well see above, and call AT&T and tell them that that they better get 
started writing everything in Ada right away! :-) It is true that
Ada was designed from the start to yield better programs. Though it
was based on existing languages, there was no legacy code to have to
maintain when justifing language aspects. When the ANSI standard was
submitted for public review, I believe the strongest objection was 
that the language was *huge*, and this was before OO extension were
added.

>> I would also like to point out that technical superiority is not always
>> a good indicator of success.
>
>  No argument there.
>
>  [snip, snip ]
>
>> system that it is an Ada compiler. To even call it an Ada compiler it
>> must pass a validation suite.
>
>  Exactly!  Though passing validation does not ensure total quality, it
>  is a first step in that direction.
>
>> The problem information systems managers have is today you must
>> incorporate PC users. Why develope a schizophrenic additute of doing
>> one with the domant tool (C/C++) and the other with Ada? I can see keeping
>> working in COBOL, but if you were to switch, switch to C++.
>
>  Au contraire. Ada is unique in its direct support for legacy COBOL
>  systems through a set of data types, Annexes, and other pre-defined
>  packages.  In fact, no contemporary object-oriented programming
>  language is as hospitable to COBOL as Ada. Ada is a perfect fit for
>  the Information Systems Manager seeking solutions for modernizing
>  exisiting COBOL-based software.
>
>> I don't think AT&T is going to start coding thier switching systems
>> in Ada just because it a better language, either.
>
>  I am manifestly unimpressed by this argument.

For more unimpressedness, manifestly or otherwise, please reread above. :-) 

>> >  Today's C++ software is tomorrow's legacy system.
>> >
>>
>> Doubtfull, very doubtfull
>
>  After all is said, we can be assured that 100 years from now, our
>  successors, whatever they might be called, will regard our efforts
>  at designing software languages with the same high esteem we reserve
>  for mathematicians in the time of Charlemagne.

It is important to have a historical perspective on things.


Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[David Weller]

In article <4v5pis$4h1@mtinsc01-mgt.ops.worldnet.att.net>,
Craig Franck  <clfranck@worldnet.att.net> wrote:
>probably does more harm than good! I feel that the level of support 
>for C/C++ on Windows and UNIX platforms is the best of any language.

There are many reasons, most economic, why C/C++ has widespread
support on WinTel and Unix platforms.  Hopefully you're not attempting
to take the position that this majority proves technical superiority
(in reality, no language is "superior" without a specific set of
criteria to measure from, and I've yet to see a comprehensive,
unbiased list that does so :-)

>Yes, you can program in Ada on a UNIX platform but I would point 
>out that the compiler is written in C

I would point out that you should get your facts straight before
making a public comment seen by thousands of readers that you're
unable to substantiate.  Of the three Ada compilers I've used for
Unix, all three were written in Ada (with a few percentage points of C
and assembler).  I'm open for refutation.

>find myself falling victim to time and time again. Like when I'm
>writing : how many OSs or compilers are written in Ada? And not as
>an acedemic exercise to prove it is possible, but in actual use?
> 
Again, I don't really believe this proves much.  NeXTStep is in
Objective-C.  BiiN OS was written in Ada, as well as the OS for the
original Rational "Delta" machines.  Does that mean that Ada won't
become a language for "serious" programming (as if all us Ada people
wore clown suits to work :-) until we have our own widespread OS?
The focus of Ada is on multi-language (both human and computer)
support, while preserving reliability AND efficiency.  C/C++ grew from
a different perspective.

>I were to ride on the space shuttle, I would be concerned with how
>well the software was written and tested, not what language it
>was written in. 

I agree, but I'd be even more concerned with the engineering decisions
being made before the system is designed.  In a nutshell, the Ariane 5
rocket blew up because engineering management deliberately made a
decision to avoid testing a specific situation because they didn't
think it was critical enough!

>maintain when justifing language aspects. When the ANSI standard was
>submitted for public review, I believe the strongest objection was 
>that the language was *huge*, and this was before OO extension were
>added.
>

*Whew*  Good thing the ISO folks saw that error and corrected it:  Now
the ISO C++ draft standard is 20% larger than the Ada 95 standard!  

By the way, one should NEVER confuse "large" with "complex".  

>It is important to have a historical perspective on things.
>
Yes, but if your "facts" on Ada are more than two years old, they're
outdated!


-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: C is 'better' than Ada because...

[Mike Stark]

Richard Riehle wrote:
> 
> Darrin Smith (fignet05.darrins@eds.com) wrote:
>   In article <Pine.GSO.3.92.960726122347.25896E-100000@nunic.nu.edu>,
>   rriehle@nunic.nu.edu says...
> 
><<snip>>
>   Darrin,
> 
>   I welcome your differing point-of-view but would prefer that
>   we not resort to pejoratives in discussing it, OK.
> 
> <snip>
> 
>   C++ and C are probably fine for certain classes of problems, but they
>   are certainly archaic when compared to the progress being made in
>   the world of programming languages. And I do not refer only to Ada in
>   that last sentence.  Eiffel also comes to mind as a preferred
>   alternative to C++.

..and IMHO Java is headed that way, although it currently lacks some
useful basics (like formatted text input & output) it is a much safer,
less complex language design, and it comes with the GUI library
provided by AWT.
> 
>   Today's C++ software is tomorrow's legacy system.
> 
>   Richard Riehle

Re: C is 'better' than Ada because...

[Robert Dewar]

Darrin asks

""Why Ada?  Who has ever proven it to be better than COBOL for typical business
apps?"

Well first of all the claim only makes sense for Ada 95, and of course no
one has proven any such thing, since there has barely been enough time to
do preliminary prototype implementations, let alone comparative evaluations.

However, speaking as someone who knows COBOL and Ada 95 well (I am probably
one of the only people who has done both a COBOL validation and an Ada 95
validation :-) I would say that it is a reasonable proposition.

The information systems annex capabilities provide the key support that
is missing in Ada 83 for scaled decimal arithmetic, and picture processing,
and these are the only two areas in which COBOL is otherwise potentially
superior (and was superior to Ada 83).

Otherwise the standard features of Ada (stronger typing, better abstraction
capabilities, runtime checking ...) seem to me clearly superior to what
COBOL has to offer. I am quite a fan of COBOL, but it does show the
problems of being built on a somewhat kludgy foundation.

Re: C is 'better' than Ada because...

[Doug & Rose Miller]

Craig Franck <clfranck@worldnet.att.net> wrote:
+Richard Riehle <rriehle@nunic.nu.edu> wrote:
+
+>  C++ and C are probably fine for certain classes of problems, but they
+>  are certainly archaic when compared to the progress being made in
+>  the world of programming languages. And I do not refer only to Ada in
+>  that last sentence.  Eiffel also comes to mind as a preferred
+>  alternative to C++.
+
+
+I agree with that, if you include PC programming as "a certain class of
+problems". Most PC OS's are written in C/C++. It makes sense that
+applications would then be coded in C/C++ as well.

This is absolute nonsense. IBM mainframe operating systems are (or at
least were, during the time I worked with them) written in assembly language;
by this "reasoning,"  application programming on IBM mainframes should
therefore also be done in assembly language.

What possible connection is there between the language used to write an
OS, and the language in which the applications which run under it are written?

Re: C is 'better' than Ada because...

[Craig Franck]

dlmiller@inetdirect.net (Doug & Rose Miller) wrote:
>Craig Franck <clfranck@worldnet.att.net> wrote:
>+Richard Riehle <rriehle@nunic.nu.edu> wrote:
>+
>+>  C++ and C are probably fine for certain classes of problems, but they
>+>  are certainly archaic when compared to the progress being made in
>+>  the world of programming languages. And I do not refer only to Ada in
>+>  that last sentence.  Eiffel also comes to mind as a preferred
>+>  alternative to C++.
>+
>+
>+I agree with that, if you include PC programming as "a certain class of
>+problems". Most PC OS's are written in C/C++. It makes sense that
>+applications would then be coded in C/C++ as well.
>
>This is absolute nonsense. IBM mainframe operating systems are (or at
>least were, during the time I worked with them) written in assembly language;
>by this "reasoning,"  application programming on IBM mainframes should
>therefore also be done in assembly language.

While it might not be in your mind a compelling argument, I dont believe
it is nonsensical. Having programmed for Windows in C/C++, Pascal as well as
BASIC, I feel that C/C++ is the most natural. Pascal does not use NULL
terminalted strings. In BASIC everything is passed by reference, so 
you had to create a ByVal keyword. Also do to some limitations of Visaul
Basic, you can't even include all of windows.h in an application, so you
must hunt for the declarations you want and put them in. Perhaps it's the
implenentations not the languages themselves. When you are using the 
same tools the vendor used to write the OS your going to be using a good
implementation. The only Ada compiler I have is for DOS so I tend to view
it as good for learning the language, but not much else. Also so you
*must* admit that lingua prima of the PC world is C/C++, with Pascal and
BASIC taking up the rear. There must be a reason for this even if the
one I gave is not satisfactory. Perhaps as psycholigists say you can
be a victim of the run of your patients. In UNIX there is a lot more
support for C than Ada, so if I were start a project I would pick C
not Ada. There have been pure Lisp machines in which the whole OS was
written in Lisp. Also there is Oberon which is a pure enviroment-- not
just a language. Theoretically you could program in any language. The 
question is how can I get the most done? I have a bias towards these
types of implementation because they have worked well for me in
the past. Perhaps your experiences have been different.


>What possible connection is there between the language used to write an
>OS, and the language in which the applications which run under it are written?

It seems that those languages have the best implementations.  And yes
if the OS is written in assembler, you are better off with a HLL for that
is the best way to leverage your time.



-- 

Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[Doug & Rose Miller]

Craig Franck <clfranck@worldnet.att.net> wrote:
+dlmiller@inetdirect.net (Doug & Rose Miller) wrote:
+>Craig Franck <clfranck@worldnet.att.net> wrote:
+>+Richard Riehle <rriehle@nunic.nu.edu> wrote:
+>+
+>+>  C++ and C are probably fine for certain classes of problems, but they
+>+>  are certainly archaic when compared to the progress being made in
+>+>  the world of programming languages. And I do not refer only to Ada in
+>+>  that last sentence.  Eiffel also comes to mind as a preferred
+>+>  alternative to C++.
+>+
+>+
+>+I agree with that, if you include PC programming as "a certain class of
+>+problems". Most PC OS's are written in C/C++. It makes sense that
+>+applications would then be coded in C/C++ as well.
+>
+>This is absolute nonsense. IBM mainframe operating systems are (or at
+>least were, during the time I worked with them) written in assembly language;
+>by this "reasoning,"  application programming on IBM mainframes should
+>therefore also be done in assembly language.
+
+While it might not be in your mind a compelling argument, I dont believe
+it is nonsensical. Having programmed for Windows in C/C++, Pascal as well as
+BASIC, I feel that C/C++ is the most natural.

Perhaps. But this has absolutely nothing to do with the language in which
the OS was written. How could it? The OS isn't executing source code. It's
executing object code, and you can't tell what the source language was,
by looking at the object code.

<language-specific irrelevancies deleted>

+ When you are using the
+same tools the vendor used to write the OS your going to be using a good
+implementation.

I'm completely baffled as to why you think there's any connection.

<more language-specific irrelevancies deleted>

+ Theoretically you could program in any language. The
+question is how can I get the most done? I have a bias towards these
+types of implementation because they have worked well for me in
+the past. Perhaps your experiences have been different.
+

Not only different, but a little broader, too, I'd suspect.  Sounds to me
like your experiences have been limited to a single platform.

+
+>What possible connection is there between the language used to write an
+>OS, and the language in which the applications which run under it are written?
+
+It seems that those languages have the best implementations.  And yes
+if the OS is written in assembler, you are better off with a HLL for that
+is the best way to leverage your time.
+

You just contradicted yourself, you know. Earlier you said "When you are using the
same tools the vendor used to write the OS your going to be using a good
implementation." Now you say that a high-level language is the best application
environment when the OS is written in assembly.

And whether you are better off with a HLL or assembly depends entirely on
the problem you are solving, and has absolutely nothing to do with the language
in which the OS was written.

Re: C is 'better' than Ada because...

[Craig Franck]

dlmiller@inetdirect.net (Doug & Rose Miller) wrote:
>Craig Franck <clfranck@worldnet.att.net> wrote:
>+dlmiller@inetdirect.net (Doug & Rose Miller) wrote:
>+>Craig Franck <clfranck@worldnet.att.net> wrote:
>+>+Richard Riehle <rriehle@nunic.nu.edu> wrote:

>+>+I agree with that, if you include PC programming as "a certain class of
>+>+problems". Most PC OS's are written in C/C++. It makes sense that
>+>+applications would then be coded in C/C++ as well.
>+>
>+>This is absolute nonsense. IBM mainframe operating systems are (or at
>+>least were, during the time I worked with them) written in assembly language;
>+>by this "reasoning,"  application programming on IBM mainframes should
>+>therefore also be done in assembly language.
>+
>+While it might not be in your mind a compelling argument, I dont believe
>+it is nonsensical. Having programmed for Windows in C/C++, Pascal as well as
>+BASIC, I feel that C/C++ is the most natural.
>
>Perhaps. But this has absolutely nothing to do with the language in which
>the OS was written. How could it? The OS isn't executing source code. It's
>executing object code, and you can't tell what the source language was,
>by looking at the object code.
>
How could it? The fact that all the API functions want NULL terminated
strings is a clue. So when you want to pass a string from a Pascal 
program, you can't pass it a string with the length embeded in the first
element of the string/array. The fact that you need a new keyword in BASIC
because it expects things to be passed by value. I know it's all just 1's and
0's when its object code, but to interface with the OS you must call 
API functions, and it's there where you must deal with the language that
the OS is written in. Subroutine linkage is language specific. So yes,
you at least need to know what that should be. Fortran, BASIC and Pascal
have similar linkage. C does not.


>+ When you are using the
>+same tools the vendor used to write the OS your going to be using a good
>+implementation.
>
>I'm completely baffled as to why you think there's any connection.

Because my C++ compiler and assembler both come from Microsoft. Look,
it helps because I can do things like write custom controlls and DLL's
that act as part of the OS and thus extend it. So don't be baffled. I
think there is a conection because in my case, there is. This would not
be true in a general sense, but Microsoft is an 800 pound gorilla, and
if you do things their way, then when they upgrade thier OS your 
programs still run on that platform. Which is real important.

>+ Theoretically you could program in any language. The
>+question is how can I get the most done? I have a bias towards these
>+types of implementation because they have worked well for me in
>+the past. Perhaps your experiences have been different.
>+
>
>Not only different, but a little broader, too, I'd suspect.  Sounds to me
>like your experiences have been limited to a single platform.

Actually, a small number. DOS/Windows is what I develope seriously
on.

>+
>+>What possible connection is there between the language used to write an
>+>OS, and the language in which the applications which run under it are written?
>+
>+It seems that those languages have the best implementations.  And yes
>+if the OS is written in assembler, you are better off with a HLL for that
>+is the best way to leverage your time.
>+
>
>You just contradicted yourself, you know. Earlier you said "When you are using the
>same tools the vendor used to write the OS your going to be using a good
>implementation." Now you say that a high-level language is the best application
>environment when the OS is written in assembly.

That may seem like a contridiction. Its interesting that you brought up
mainframes running OS written in assembler. If there is not a HLL in 
which to write the OS go with assembler and write compilers for COBOL, or
PL/I or FORTRAN or whatever. Anything but assembler. I don't know what
MVS running on an ES/9000 is written in. I know AIX is a UNIX clone so
I would assume its written in C. So what do you think? Someones going
to develop in assembler just because it's a could implementation?
That would not be the best way to leverage ones time as a programmer.
But assembler is the exception, not the rule.
 
>And whether you are better off with a HLL or assembly depends entirely on
>the problem you are solving, and has absolutely nothing to do with the language
>in which the OS was written.
>

That not true! DOS was written in assembler. In the beggining you needed
an INT 21 to interface with the OS. You could buy a C compiler but if 
you looked at the source for the library functions, the ones that called
the API were all part assembler. Now if you didn't say "depends entirely"
I would have agreed with you because your statement is true in a 
general sense. 

You are correct that the problem should determine the solution. But 
there is legacy code. Is AT&T going to rewrite or start coding all their
switching systems in Ada just because it's "better"? I dont think so. 

I only threw that in at the last minute because the name of this 
thread is C is "better" than Ada... :-)

Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[nasser]

In article <4um08t$klq@mtinsc01-mgt.ops.worldnet.att.net>, Craig says...
>
>dlmiller@inetdirect.net (Doug & Rose Miller) wrote:
>>....The OS isn't executing source code. It's
>>executing object code, and you can't tell what the source language was,
>>by looking at the object code.
>>

>How could it? The fact that all the API functions want NULL terminated
>strings is a clue. So when you want to pass a string from a Pascal 
>program, you can't pass it a string with the length embeded in the first
>element of the string/array. The fact that you need a new keyword in BASIC
>because it expects things to be passed by value. I know it's all just 1's and
>0's when its object code, but to interface with the OS you must call 
>API functions, and it's there where you must deal with the language that
>the OS is written in. Subroutine linkage is language specific. So yes,
>you at least need to know what that should be. Fortran, BASIC and Pascal
>have similar linkage. C does not.


Offcourse on a real solid OS like VMS (the best OS of them all), the interface
to system services, system libraries, and the rest, is an API that is
not specific to one programming language, it is language idependent
API, and this is how an API should be. An OS API that is designed to make it
easier to be used by one langauge and not the other is not a good API.

You might want to have a look at some of the VMS system services calls to
see for yourself.

Nasser
--
Nasser Abbasi. C/C++/Ada Solaris. Perkin Elmer - Applied BioSystem division. 
email:  nasser@apldbio.com   MSEE, MSCS, MSCE, Fide chess master (FM).

"640K ought to be enough for anybody."   -- Bill Gates, 1981

"I think there is a world market for maybe five computers." 
Thomas Watson,  chairman of IBM, 1943

"There is no reason anyone would want a computer in their home." 
Ken Olson, president, chairman and founder of Digital Equipment Corp., 1977

"This 'telephone' has too many shortcomings to be seriously considered
as a means of communication."   Western Union internal memo, 1876.

"Heavier-than-air flying machines are impossible."
Lord Kelvin, president, Royal Society, 1895.

"Everything that can be invented has been invented."
Charles H. Duell, Commissioner, U.S. Office of Patents, 1899.

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <4ul434$jf@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> While it might not be in your mind a compelling argument, I dont believe
> it is nonsensical. Having programmed for Windows in C/C++, Pascal as well as
> BASIC, I feel that C/C++ is the most natural. Pascal does not use NULL
> terminalted strings.

This is not a problem in Ada.  See Ada.Interfaces.C, which has full support
for interoperation with C stuff (including strings, pointers, and whatnot).
Works like a champ.

> When you are using the 
> same tools the vendor used to write the OS your going to be using a good
> implementation.

Hmmm, MS would seem to be a counterexample to this claim. MSVC++ is
hardly a "good" impl of C++ under any reasonable interpretation.


> The only Ada compiler I have is for DOS so I tend to view
> it as good for learning the language, but not much else.

Well, GNAT is freely available for DOS, Win95 and WinNT.  ObjectAda
from Tomson is in the same price range as MSVC++ and has the full
blown IDE and Windoze support (with GUI builder and all...)


> Also so you
> *must* admit that lingua prima of the PC world is C/C++, with Pascal and
> BASIC taking up the rear.

It is "lingua prima", but for no reason other than inertia.  But
inertia is hard to beat.  As we all know, people are in general
mentally lazy and don't like learning anything different (let alone
new).  Programmers seem to exhibit this attitude even more than the
average joe/jane.


> be a victim of the run of your patients. In UNIX there is a lot more
> support for C than Ada, so if I were start a project I would pick C
> not Ada. There have been pure Lisp machines in which the whole OS was

Here we have the problem of perception again.  And inertia...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Doug & Rose Miller]

Craig Franck <clfranck@worldnet.att.net> wrote:

+Yes, you can program in Ada on a UNIX platform but I would point
+out that the compiler is written in C. If C/C++ are your primary
+languages for writting system software, when it's time to write
+an application that might seen like the best language to use.

Yes, it might =seem= like the best language to use -- to someone
who lacks understanding of how to select an appropriate language
for solving a given task.

The best language to use for an application is the one which best
maps that application to the virtual machine on which it will run.

This has absolutely no connection to the language in which the
system software was written.

Re: C is 'better' than Ada because...

[Craig Franck]

dlmiller@inetdirect.net (Doug & Rose Miller) wrote:
>Craig Franck <clfranck@worldnet.att.net> wrote:
>
>+Yes, you can program in Ada on a UNIX platform but I would point
>+out that the compiler is written in C. 

I have since become aware that this statement is false. It has
also been pointed out that C++ compilers are available that 
have been written entirely in Ada95 as well.

>+If C/C++ are your primary
>+languages for writting system software, when it's time to write
>+an application that might seen like the best language to use.
>
>Yes, it might =seem= like the best language to use -- to someone
>who lacks understanding of how to select an appropriate language
>for solving a given task.
>
>The best language to use for an application is the one which best
>maps that application to the virtual machine on which it will run.
>
>This has absolutely no connection to the language in which the
>system software was written.

This is true as well. The problem now becomes which language maps
the application on to the target machine the best. Saying "the one that
I'm familar with" might seem like a lame answer, but if that 
language is the best choice, then there should certainly be no bias
against it.  It might be that low level languages are good at 
manipulating hardware and higher level languages are good at manipuling
abstractions. Languages that do both (ie. C++/Ada95) would allow alot
of your programming to be done in them with some in database or utility
(ie. postscript or transaction processing script) languages. 
 
Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[Ken Garlington]

Michael Feldman wrote:
> 
> Anything you'll get these days will be at least as reliable as the
> typical C compiler. There is absdolutely no reason why they shouldn;t be.
> Sure, there were pretty rotten Ada compilers 10 years ago, but there
> have been rotten C compilers too.

Some reasons why you might still get a rotten Ada (probably 83) compiler:

1. You're the first user from a particular (and particularly challeging) 
application domain. [Been there.]

2. You are the first user of a compiler that just underwent a major port/
rewrite/etc. [Also there.]

3. You're the only remaining user of a compiler that hasn't been updated in
many years. (vendor's out of business, host is now obsolete, etc.) [There, too.]

4. You forgot (or couldn't afford) to buy maintenance! [Not been there, yet!]

Of course, I suspect these also apply to C compilers, so it's not a 
language-unique issue...

> There's also a vicious-circle effect - if system designers avoid the
> tasking implementation and go down to the OS or the bare iron instead,
> what incentive do compiler builders have to improve the tasking?

Money (e.g. a competitive advantage), I would expect.

I never buy this argument, for two reasons: (1) How do vendors know the
proportion of Ada features used by their customer base? Do they do surveys?
Read user code? Look at problem reports (see below)? (2) Good marketing
_creates_ demand; it doesn't just wait for enough users to ask for something.
(he said, fully realizing that he's in a minority of one when it comes to the 
application of this idea to Ada... :)

> The best way to get well-optimized tasking is to _use it_.

What happens if a user tries tasking, finds that it doesn't meet their
needs with respect to capabilities, performance, etc., and writes the
vendor identifying the deficiencies? Would this qualify as using it?

Many vendors have this interesting categorization scheme that, if a
workaround exists for a problem, it's less important to fix the problem.
Unfortunately, there's always a workaround to the tasking model.

> Compiler (and runtime) builders set their priorities according to
> perceived customer need. Wouldn;t you do the same?

Actually, I think most commercial compiler/runtime builders set their
priorities based on the best likelihood of creating profits. Wouldn't you
do the same? :)

-- 
LMTAS - "Our Brand Means Quality"

Re: C is 'better' than Ada because...

[Tim Behrendsen]

Ken Garlington <garlingtonke@lmtas.lmco.com> wrote in article
<31EF7E48.5ABE@lmtas.lmco.com>...
> Sandy McPherson wrote:
> > and produce efficient machine code.
> 
> Why is this an advantage of C over Ada? Ada certainly produces efficient
> machine code, given a good compiler. In fact, there are examples of Ada
> outperforming C with regard to efficiency.

The one big advantage C has traditionally had over other
languages is efficient compilation.  The reason is that 'C' is one
of the few languages that provides concepts such as register
variables to give hints to the compiler.

Yes, you can wave your hand and say, "well, the compiler
should take care of that".  But then, reality rears its head, and
we realize that there are *no* compilers that are that smart.
Here's an old saying that I just made up ...

Behrendsen's Law: "All optimizers are crap."

We will never have an optimizer that can do as good a job
as human optimization until we get "strong AI", but that would
take an actual science of AI to exist (let's not get started on
*that*!).  C is one of few languages that recognizes this.

Since C is such a small language, this also makes it
easier for the compiler/optimizer to a (relatively) good job.

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[Lawrence Kirby]

In article <01bb7bfc$3c5ca460$96ee6fcf@timhome2>
           tim@airshields.com "Tim Behrendsen" writes:

>The one big advantage C has traditionally had over other
>languages is efficient compilation.  The reason is that 'C' is one
>of the few languages that provides concepts such as register
>variables to give hints to the compiler.

register should make minimal difference these days, I believe some
compilers ignore it (at least for optimisation purposes). Register
aloocation/colouring schemes can work at a much finer grain than
can be specified in the source code and can give better results.

>Yes, you can wave your hand and say, "well, the compiler
>should take care of that".  But then, reality rears its head, and
>we realize that there are *no* compilers that are that smart.

This depends on the archetecture. I suspect that many compilers can do
better than humans in most circumstances unless the human uses feedback
(looking at the generated assemby and tweaking which is often a case
of trial and error). Feedback compilers (i.e. where the compiler
takes profiling data to work out the most critical parts of the code
along with branch prediction data) will probably do an even better job.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: C is 'better' than Ada because...

[Ian Ward]

In article 96ee6fcf@timhome2, "Tim Behrendsen" <tim@airshields.com> () writes:
>Ken Garlington <garlingtonke@lmtas.lmco.com> wrote in article
><31EF7E48.5ABE@lmtas.lmco.com>...
>> Sandy McPherson wrote:
>> > and produce efficient machine code.
>> 
>> Why is this an advantage of C over Ada? Ada certainly produces efficient
>> machine code, given a good compiler. In fact, there are examples of Ada
>> outperforming C with regard to efficiency.
>
>The one big advantage C has traditionally had over other
>languages is efficient compilation.  The reason is that 'C' is one
>of the few languages that provides concepts such as register
>variables to give hints to the compiler.

It is true, C code does compile much faster than some languages.
However, this is done at the expense of development speed, not 
to the benefit of it. It is a matter of record now that language
development is not as fast as it could be. This is because, the 
simple checks that a good programmer will make, can be made, 
easily, by a compiler. The difference being that the compiler
_never_ forgets to do them, it _never_ doesn't do them, because
it wants to get home for Playschool, and it does them in less
time than a human takes, (from about 10 million times faster,
upwards.)

>
>Yes, you can wave your hand and say, "well, the compiler
>should take care of that".  But then, reality rears its head, and
>we realize that there are *no* compilers that are that smart.
>Here's an old saying that I just made up ...
>
>Behrendsen's Law: "All optimizers are crap."
>
>We will never have an optimizer that can do as good a job
>as human optimization until we get "strong AI", but that would
>take an actual science of AI to exist (let's not get started on
>*that*!).  C is one of few languages that recognizes this.

This also sounds good, but is inaccurate. There is documented
evidence of a company wishing to get a waiver from Ada, on the
grounds that speed was a premium, and so they wanted to opt 
for a piece of assembler. The DOD representative, apparently, 
while being open minded (I'm sure,) wanted to check whether the
Ada really was too slow, so commissioned a bit of the code in
Ada, and a bit in Assembler. To _everyone's_ surprise, the Ada
was faster.

Ward's Law : "Because of the nice ring to it, people tend to
              believe that which sounds good, over that which
              has basis in fact."

>
>Since C is such a small language, this also makes it
>easier for the compiler/optimizer to a (relatively) good job.

In fact, this is not true either, the more generally one specifies
how a compiler is allowed to do something, the more scope a compiler
has for finding efficient implementations. When the day comes, that
I can just tell a computer to "just do the housework!", then its
solution will more than likely, miles more efficient that it would
be then if I said, "Washup;Hoover;Dust;" This is obvious, because, 
while hoovering, say, the machine, can clear up empty plates as it
passes them.
(Of course it may take longer to develop the compiler to handle
the broader cases, but one can always recompile the code one
has written, with subsequent versions of the compiler, as it
improves.)

This scenario will not always be the case of course, because eventually
compilers will be effectively reverse engineering tools, that work
out the code's intention, then write the best implementation for the
problem themselves. 

This still won't help your argument either unfortunately, because,

a. simple structured languages will have died out in the same way
has walking, other than for recreation,

b. they aren't particularly well suited to describing accurately
big problems anyway, since the compiler will be able to compile
just about anything, high or low level, it would be far better suited
to working out the requirements from a high level description of
the problem,

c. unless someone discovers a new modelling technique, (I use the
word abstraction a lot, but it is not really the correct word.)
like really soon, then we will not live long enough to see it.

>
>-- Tim Behrendsen (tim@airshields.com)

Best regards,
Ian.

---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be

Re: C is 'better' than Ada because...

[Bob Cousins]

"Tim Behrendsen" <tim@airshields.com> wrote:

>Ken Garlington <garlingtonke@lmtas.lmco.com> wrote in article
><31EF7E48.5ABE@lmtas.lmco.com>...
>> Sandy McPherson wrote:
>> > and produce efficient machine code.
>> 
>> Why is this an advantage of C over Ada? Ada certainly produces efficient
>> machine code, given a good compiler. In fact, there are examples of Ada
>> outperforming C with regard to efficiency.

>The one big advantage C has traditionally had over other
>languages is efficient compilation.  The reason is that 'C' is one
>of the few languages that provides concepts such as register
>variables to give hints to the compiler.

That's complete nonsense! One of the design goals of Pascal was
efficient compilation. Every version of Borland Pascal I have used has
been far faster compiling than equivalent C compilers. Historically C
code has run a little faster than Pascal but I am willing to trade a
little run time speed for a better language.

Also, if C is so efficient at compilation why does the programmer have
to provide hints to the compiler? 


-- 
Bob Cousins, Software Engineer.
http://www.demon.co.uk/sirius-cybernetics/

Re: C is 'better' than Ada because...

[Robert Dewar]

Bob Cousins says

"That's complete nonsense! One of the design goals of Pascal was
efficient compilation. Every version of Borland Pascal I have used has
been far faster compiling than equivalent C compilers. Historically C
code has run a little faster than Pascal but I am willing to trade a
little run time speed for a better language.
"

The fact that Borland Pascal compiles faster than C says nothing about
the language -- Realia COBOL compiles faster than either of them, but
again that does not say that COBOL is more efficient to compile, just
that the compiler is faster!

Re: C is 'better' than Ada because...

[Bob Cousins]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>Bob Cousins says

>"That's complete nonsense! One of the design goals of Pascal was
>efficient compilation. Every version of Borland Pascal I have used has
>been far faster compiling than equivalent C compilers. Historically C
>code has run a little faster than Pascal but I am willing to trade a
>little run time speed for a better language.
>"

>The fact that Borland Pascal compiles faster than C says nothing about
>the language -- Realia COBOL compiles faster than either of them, but
>again that does not say that COBOL is more efficient to compile, just
>that the compiler is faster!

Ok, I made a slight leap of logic there. But I belive the compiler is
faster because the language *can* be compiled faster. I don't believe
its all or even mostly due the programmers being better or more money
has been spent on optimisation. Just compare Borland C with Borland
Pascal on the same platform. I bet Borland C had more resources spent
on it too.

If you look up N. Wirths design goals for Pascal it was specifically
designed to be able to be compiled efficiently because in a teaching
environment a lot of one-off compiles are performed. Admittedly
Borlands extensions to Pascal are helpful to compiler performance, but
the same things (units and symbol files) were built in parts of
Modula-2.

The design goal of C was to be a language for writing Unix, so it is
expected that run-time efficiency is more important than compile
speed.

Regards,
-- 
Bob Cousins, Software Engineer.
Home page at http://www.demon.co.uk/sirius-cybernetics/
Note: Commercial email to bob@lintilla.demon.co.uk will be subject to a $500 handling fee.
Sending of such email constitutes acceptance of these terms.

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <4uopmu$hod@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> My statement was a hyperbole; an extravagant exaggeration. I can
> not defend it in a literal sense. The fact the US government,
> particularly as it relates to the Military Industrial Complex
> had anything to do with the creation of Ada, makes me highly 
> suspicous. But to say something is bad just because of where
> it came from would be to commit the genetic fallacy of reasoning,
> so I won't comment on that any futher.

Hmmm, how do you feel about using news?  email?  the internet in general?
All are US DARPA funded projects.

Don't fly at all I suppose either?  Most commercial aircraft are
directly traceable to their military roots.  Or use the interstate
road system?  Or...

Now, I'd be the first to say that most things associated with the
government are pretty bad (useless, worthless, fill_in_the_blank).
But, as you seem to agree, to reason to the universal here is a bad
piece of logic.


>I think if a handfull of languages dominate, that's enough
> standardization for me.

Yes, a reasonbly sized mix of languages with widespread acceptance and
use would be great.  This is the Matt Kennel theory and it is a good one.


/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Craig Franck]

jsa@alexandria (Jon S Anthony) wrote:
>In article <4uopmu$hod@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:
>
>> My statement was a hyperbole; an extravagant exaggeration. I can
>> not defend it in a literal sense. The fact the US government,
>> particularly as it relates to the Military Industrial Complex
>> had anything to do with the creation of Ada, makes me highly 
>> suspicous. But to say something is bad just because of where
>> it came from would be to commit the genetic fallacy of reasoning,
>> so I won't comment on that any futher.
>
>Hmmm, how do you feel about using news?  email?  the internet in general?
>All are US DARPA funded projects.
>
>Don't fly at all I suppose either?  Most commercial aircraft are
>directly traceable to their military roots.  Or use the interstate
>road system?  Or...
>
>Now, I'd be the first to say that most things associated with the
>government are pretty bad (useless, worthless, fill_in_the_blank).
>But, as you seem to agree, to reason to the universal here is a bad
>piece of logic.

I'm glad you agree! I was recently told that VCR technology came
from the need to embed detailed information about an area, so a 
cruise missile could fly low to the ground and hit an exact target. 
I love watching movies so, if thats where it came from, I don't care!

Perhaps I could give you some of what I have been told, some 
theories of how programming languages spread. In the past the
government has made proclamations to the effect that if a
compiler for a certain language is not available on a piece of
computing machinery, we ain't gunna buy it. They have said in
the past (and if I'm wrong correct me, because my batting average
is a little low) that they wouldn't buy a computer for data 
processing that didn't have a COBOL compiler. The number crunchers
they were more forgiving on but having a FORTRAN compiler up and
going on a platform, shure did help. That helped these languages
spread. I have been told that what killed ALGOL was not ALGOL-68,
but the fact that IBM gave you a FORTRAN compiler(o.k if they
didn't give it to you with the computer, they still had one) and
getting an ALGOL compiler was more work. 

Now Ada comes along. Want to bid on a contract to do embeded 
systems programming? Do it in Ada, because that's what the
specifications are for the project. Got a neat little 
micro-controller we can put in something? Got an Ada compiler
for it? The point is that when the government throws it's 
weight behind something, it has an impact. Now there are lots
of reasons to do most of your programming in one language.
Saves *alot* of money, no doubt. But if someone say's we have
looked at this problem and we think Smalltalk is the best
HLL to go with and they say "didn't you read the specifications
of the project?, We are going with Ada!" that squews thing's 
in Ada's behalf. 

Now, perhaps I'm wrong again and you can just pick and choose
'tell your harts content on what language you can use on a particular
project, but if that's not the case, then perhaps a case could
be made that even if Ada was designed by the best minds on the
planet, *alot* of it's success came from it being the darling
of the DOD. It's first spefication, I believe, was DOD-1. This
in itself doesn't bother me(like I said, I still rent video's)
but quite often cloat sets standards, not technical excellence.


Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[Van Snyder]

In article <4ur9ii$7r4@mtinsc01-mgt.ops.worldnet.att.net>, Craig Franck <clfranck@worldnet.att.net> writes:

|> ... I have been told that what killed ALGOL was not ALGOL-68,
|> but the fact that IBM gave you a FORTRAN compiler(o.k if they
|> didn't give it to you with the computer, they still had one) and
|> getting an ALGOL compiler was more work. 

The biggest factor in killing Algol was that the 1960 "standard" didn't
specify I/O -- Algol, like Ada, but unlike Fortran or COBOL, has no I/O
"statements."  Unlike Ada, however, the "Report on the programming language
Algol" also failed to specify a standard I/O library interface.

-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <4ur9ii$7r4@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> computing machinery, we ain't gunna buy it. They have said in
> the past (and if I'm wrong correct me, because my batting average
> is a little low)

Rest assured someone will catch you out if you're factually wrong.
Opinions and value judgements are another matter.  This little
"history" you give is rather naive, but there are any number of views
on why this or that happened in the proliferation or lack thereof in
programming language history.


> Now Ada comes along. Want to bid on a contract to do embeded 
> systems programming? Do it in Ada, because that's what the
> specifications are for the project. Got a neat little 

Well, that was the orginal intension, but it has not happened so much
in practice or at the very least it has been widely ignored if the
various reports one sees flying around here are accurate.


> Saves *alot* of money, no doubt. But if someone say's we have
> looked at this problem and we think Smalltalk is the best
> HLL to go with and they say "didn't you read the specifications
> of the project?, We are going with Ada!" that squews thing's 
> in Ada's behalf. 

It would be wrong and stupid.  It probably has happened.  Just like
when "Me too!" wannabe fadophile managers insist that you must use C++
when an Ada solution is clearly superior.  OTOH, as I say, the
evidence strongly suggests that people pretty much use whatever they
want to use irrespective of merit or legality.


> Now, perhaps I'm wrong again and you can just pick and choose
> 'tell your harts content on what language you can use on a particular
> project

The evidence seems to suggest that this is more or less true _in
practice_.  And again, it is true even when the language chosen is NOT
Ada and Ada would clearly have been _more_ appropriate.


> planet, *alot* of it's success came from it being the darling
> of the DOD

I'm sure you don't realize just how absolutely hilarious this
statement is to the c.l.a audience.  Ada is hardly the "darling" of
the DoD (which seems to have jumped on the C++ fadomobile with a lot
of "Me too!  Me too!" brain dead behavior).  It maybe _should_ be,
but that's not the same thing.


> It's first spefication, I believe, was DOD-1. This

??? Where'd you come up with this one???  The original Ada did have a
Mil Std reference # (in addition to ANSI and ISO #s), which happened
to be 1815 (year or Ada's birth).


> in itself doesn't bother me(like I said, I still rent video's)
> but quite often cloat sets standards, not technical excellence.

Sure.  Like AT&T or MS and C or C++ or DOS or Windoze or...  You gotta
keep this in perspective: Big Dumbo companies can be every bit as
stupid, clumsy, incompetent and beauracratic as government.  And
likewise, there are times when specific people involved can rise above
this sorry state of affairs.

Ada is technically _very_ good (nothing to do with software is
excellent) and I have said in the past that the worst thing to happen
to Ada was the government.  Because of all these goofy perception
problems.  Of course, the flip side is that it wouldn't have happened
without the government either.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Craig Franck]

jsa@alexandria (Jon S Anthony) wrote:
>In article <4ur9ii$7r4@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

>> It's first spefication, I believe, was DOD-1. This
>
>??? Where'd you come up with this one???  The original Ada did have a
>Mil Std reference # (in addition to ANSI and ISO #s), which happened
>to be 1815 (year or Ada's birth).

Norman Cohen's fine book on the Ada programing langauage states
that "In April 1975, the Higher Order Language Working Group
issued a set of sample requirements for DoD-1". I clearly 
miss spoke when I called this a specification. The working
requirement were refined and given the names (colorfully
enough) Strawman, Woodenman, Tinman, Ironman, and Steeleman.
These requirement led up to the Ada programming language, but you 
are right, these should not be confused with official standardized 
specifications.

I have often wondered if Jack Cooper picked Ada Augusta to
name the language after because, while she is considered by some 
to be the first programmer, all the other names in the 
requirements were masculine. If so, the name might be a pun of 
sorts, like C++ "incrementing" C's capabilities.

>Ada is technically _very_ good (nothing to do with software is
>excellent) and I have said in the past that the worst thing to happen
>to Ada was the government.  Because of all these goofy perception
>problems.  Of course, the flip side is that it wouldn't have happened
>without the government either.

Yes, to the informed many misinfored perceptions appear goofy!
I think if more books on Ada were available to the general 
programming public, these perceptions would change. In a recent
trip to a book store I counted 280 books with C/C++ in the title
(it's a big Barnes & Noble) and just 4 on Ada. Only 1 of which
had Ada 95 in the title. Fortunately there are abundant resources on
the Internet.

I think it's true that with Ada, having been a Pascal programmer
helps you to master the syntax. One of the complaints I have heard
from C/C++ programmers is that you have to write procedure or function; why 
can't the compiler just figure out what you are doing from the
syntax? This I think lies at the hart of some of peoples dislike for
the wordiness of the language. I have never understood the use
of the keyword "is" to help the parse, and why attributes are 
implemented the way they are, but after you have learned the language, the
syntactic style is much less important than what you can do with
it. I think that multitasking being implemented at the language
level as well as module linkage, is a big plus and separates it 
from C/C++. It comes with an over head, and I am not making any
judgements as to which language is better by saying this.

Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[Joe Gwinn]

In article <4utuag$ii9@mtinsc01-mgt.ops.worldnet.att.net>, Craig Franck
<clfranck@worldnet.att.net> wrote:

> Norman Cohen's fine book on the Ada programing langauage states
> that "In April 1975, the Higher Order Language Working Group
> issued a set of sample requirements for DoD-1". I clearly 
--->                                      ^^^^^

If I recollect, "DoD-1" was the original name for COBOL, back when Grace
Hopper was young, and I was playing with blocks.  I guess this is the
first example of Ada reuse.

Joe Gwinn

Re: C is 'better' than Ada because...

[Don Nelson]

Joe Gwinn wrote:
> 
> In article <4utuag$ii9@mtinsc01-mgt.ops.worldnet.att.net>, Craig Franck
> <clfranck@worldnet.att.net> wrote:
> 
> > Norman Cohen's fine book on the Ada programing langauage states
> > that "In April 1975, the Higher Order Language Working Group
> > issued a set of sample requirements for DoD-1". I clearly
> --->                                      ^^^^^
> 
> If I recollect, "DoD-1" was the original name for COBOL, back when Grace
> Hopper was young, and I was playing with blocks.  I guess this is the
> first example of Ada reuse.

Actually, the first COBOL book published by the DOD was "Report to 
Conference on Data Systems Languages Including Initial Specifications 
for a Common Business Oriented Language (COBOL) for Programming 
Electronic Digital Computers" in April of 1960.  I am reading this 
from the cover.  As far as I recall, this was never called DoD-1.  The 
next one said about the same thing but "Initial" was "Revised".  It 
was published in June of 1961 (and cost the amazing sum of $1.25 - you 
could purchase about three quarts of beer at my local saloon for that 
in 1961).  It came to be called DOD-61.  I was playing with computers 
then and Grace was in her 50s (which is young to me).

-- 
Don Nelson
COBOL Development, Tandem Computers, Inc.
Member, ANSI X3J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees
nelson_don@tandem.com
No clever quotes here

Re: C is 'better' than Ada because...

[Joe Gwinn]

I believe you.  It sounds like you were there, and, as I said, I was
playing with blocks then.  Well, cars.  I once read an article claiming
that DoD-1 was the original name for what became COBOL, but had no direct
evidence.  Maybe, the "DoD-61" was clipped to "DoD-1" somewhere, and the
mistake stuck.  

But, clearly, if COBOL was DoD-61, there must have been a DoD-1 before
COBOL, so Ada cannot be the first to have been called DoD-1.

Joe Gwinn


In article <3214B870.19B@tandem.com>, Don Nelson <nelson_don@tandem.com> wrote:

> Joe Gwinn wrote:
> > 
> > In article <4utuag$ii9@mtinsc01-mgt.ops.worldnet.att.net>, Craig Franck
> > <clfranck@worldnet.att.net> wrote:
> > 
> > > Norman Cohen's fine book on the Ada programing langauage states
> > > that "In April 1975, the Higher Order Language Working Group
> > > issued a set of sample requirements for DoD-1". I clearly
> > --->                                      ^^^^^
> > 
> > If I recollect, "DoD-1" was the original name for COBOL, back when Grace
> > Hopper was young, and I was playing with blocks.  I guess this is the
> > first example of Ada reuse.
> 
> Actually, the first COBOL book published by the DOD was "Report to 
> Conference on Data Systems Languages Including Initial Specifications 
> for a Common Business Oriented Language (COBOL) for Programming 
> Electronic Digital Computers" in April of 1960.  I am reading this 
> from the cover.  As far as I recall, this was never called DoD-1.  The 
> next one said about the same thing but "Initial" was "Revised".  It 
> was published in June of 1961 (and cost the amazing sum of $1.25 - you 
> could purchase about three quarts of beer at my local saloon for that 
> in 1961).  It came to be called DOD-61.  I was playing with computers 
> then and Grace was in her 50s (which is young to me).
> 
> -- 
> Don Nelson
> COBOL Development, Tandem Computers, Inc.
> Member, ANSI X3J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees
> nelson_don@tandem.com
> No clever quotes here

Re: C is 'better' than Ada because...

[Ken Garlington]

Joe Gwinn wrote:
> 
> But, clearly, if COBOL was DoD-61, there must have been a DoD-1 before
> COBOL, so Ada cannot be the first to have been called DoD-1.

Given that the revised report was published in '61, I'm not sure why there
would have to have been a DoD-1 (1901) preceding it.

Clearly, DoD-1 (Ada) should have been DoD-80 or something like that. Of course,
you _could_ argue that the designers of Ada were looking forward to 2001... :)

-- 
LMTAS - "Our Brand Means Quality"

Re: C is 'better' than Ada because...

[Van Snyder]

In article <JSA.96Aug14133011@alexandria>, jsa@alexandria (Jon S Anthony) writes:
|> In article <4ur9ii$7r4@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:
...
|> > It's first spefication, I believe, was DOD-1. This
|> 
|> ??? Where'd you come up with this one???  The original Ada did have a
|> Mil Std reference # (in addition to ANSI and ISO #s), which happened
|> to be 1815 (year or Ada's birth).

The first _specification_ for Ada wasn't DOD-1.  But pre-Ada, there were at least
three _requirements_ documents, known as "Strawman" "Ironman" and "Steelman",
and then a design competition in which IBM, Stanford Research Institute,
Honeywell and Jean Ichbiah submitted designs.  (I was one of the reviewers of
both the requirements documents, and the design competition.)  Ichbiah won.

The _requirements_ documents and the design competition were, at least
colloquially, if not officially, called "DOD-1".

BTW, the first programming language standardized was COBOL -- not by ASA (the
ANSI predecessor), but it was oficially known as "DOD Standard COBOL 60".

The first language standardized, however, wasn't a programming language.  It was
French, in the 16'th century.

-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: C is 'better' than Ada because...

[Norman H. Cohen]

In article <5004op$ir4@netline-fddi.jpl.nasa.gov>, vsnyder@math.jpl.nasa.gov
(Van Snyder) writes: 

|> and then a design competition in which IBM, Stanford Research Institute,
|> Honeywell and Jean Ichbiah submitted designs.  (I was one of the reviewers of
|> both the requirements documents, and the design competition.)  Ichbiah won.

Not quite.  The four competitors were: 

   CII-Honeywell-Bull (Ichbiah's team) -- the Green language
   Intermetrics -- the Red language
   SofTech -- the Blue language
   SRI International -- the Yellow language

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: C is 'better' than Ada because...

[Stefan 'Stetson' Skoglund]

Nja, the idea with the urgent flag in IP is being able to
side-step badly overstrained links with small traffic-control
packets. Not getting access to secret US government-owned
links or routers.

-- 
---------------------------------------------------------------------
Stefan 'Stetson' Skoglund          I               |
sp2stes1@ida.his.se                I               |
<http://www.his.se/ida/~sp2stes1/> I         _____/0\_____
                                   I ____________O(.)O___________
H\"ogskolan i Sk\"ovde, Sverige    I      I-+-I    O    I-+-I
                                   I
                                   I      Viggen with two Rb04
---------------------------------------------------------------------

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <4utuag$ii9@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> I have often wondered if Jack Cooper picked Ada Augusta to
> name the language after because, while she is considered by some 
> to be the first programmer, all the other names in the 
> requirements were masculine. If so, the name might be a pun of 
> sorts, like C++ "incrementing" C's capabilities.

Criminey.  No one could be that subtle.  Could they?


> Yes, to the informed many misinfored perceptions appear goofy!
> I think if more books on Ada were available to the general 
> programming public, these perceptions would change. In a recent
> trip to a book store I counted 280 books with C/C++ in the title
> (it's a big Barnes & Noble) and just 4 on Ada. Only 1 of which
> had Ada 95 in the title. Fortunately there are abundant resources on
> the Internet.

A chicken or egg problem if there ever was one.  Bookstore managers
are some of the most fad/pop oriented folks around (for obvious
reasons).  So, the only way to change this would be for more people to
actually request one or more of the many good books available but not
readily so from your local general book store.


> helps you to master the syntax. One of the complaints I have heard
> from C/C++ programmers is that you have to write procedure or
> function; why can't the compiler just figure out what you are doing
> from the syntax?

Well, of course it can.  The reason it is the way it is is because
of an explicit decision to keep the two types of capabilities more
obviously visually distinct (for readability etc.)  Shrug.  It's not
that big of a deal.


> This I think lies at the hart of some of peoples dislike for
> the wordiness of the language.

Probably for some people, but then those are the sorts that only have
a superficial understanding of software anyway.


> I have never understood the use
> of the keyword "is" to help the parse

_Some_ token is nice here, IMO (I'd have to check, but I don't think
the grammar actually needs it).  Why "is" and not, e.g, a
Pascal/Modula-n "="?  I don't know.  Maybe it's a "French thing"...


>? and why attributes are 
> implemented the way they are,

You mean the ' syntax and not "how they are implemented", I presume.
Again, I don't know why it was chosen.  It does have its problems.
But, I will say that I didn't like it at first, but have since come to
change my mind and am now positive about it (despite the problems...)


> but after you have learned the language, the
> syntactic style is much less important than what you can do with
> it.

Agreed. And, in general, the semantic structure of the language.
Syntax is not unimportant, but certainly much less important.


> I think that multitasking being implemented at the language
> level as well as module linkage, is a big plus and separates it 
> from C/C++. It comes with an over head, and I am not making any
> judgements as to which language is better by saying this.

It does not come with a _distributed_ overhead.  If you don't use
tasking, you pay no overhead for it being in the language.  You may
pay a few extra cycles at _compile_ time (things like the separate
issue vis-a-vis task masters), but not in your resulting code.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[nasser]

In article <JSA.96Aug15152839@alexandria>, jsa@alexandria says...
>
>In article <4utuag$ii9@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:
>
>> Yes, to the informed many misinfored perceptions appear goofy!
>> I think if more books on Ada were available to the general 
>> programming public, these perceptions would change. In a recent
>> trip to a book store I counted 280 books with C/C++ in the title
>> (it's a big Barnes & Noble) and just 4 on Ada. Only 1 of which
>> had Ada 95 in the title. Fortunately there are abundant resources on
>> the Internet.
>
>A chicken or egg problem if there ever was one.  Bookstore managers
>are some of the most fad/pop oriented folks around (for obvious
>reasons).  So, the only way to change this would be for more people to
>actually request one or more of the many good books available but not
>readily so from your local general book store.
>

I once did just that.

I asked a manager for Barnes&Noble store why he only have one
Ada book in the whole store and why he does not put more Ada books on the
shelfs, he turned and asked me: what is Ada? , I told him it is a programming
langauge, he told me : He has plenty of C/C++ books If I would be interested!
I asked him again if he could get more Ada books to put on the shelfs, he
told me that he only gets what there is demand for, I said if people do
not see Ada books, how can they buy them? he then said that these books
and what books are ordered, all come down from the "central" office.

It is a chicken and egg problem for sure.

Nasser
--
Nasser Abbasi. C/C++/Ada Solaris. Perkin Elmer - Applied BioSystem division. 
email:  nasser@apldbio.com   MSEE, MSCS, MSCE, Fide chess master (FM).

"640K ought to be enough for anybody."   -- Bill Gates, 1981

"I think there is a world market for maybe five computers." 
Thomas Watson,  chairman of IBM, 1943

"There is no reason anyone would want a computer in their home." 
Ken Olson, president, chairman and founder of Digital Equipment Corp., 1977

"This 'telephone' has too many shortcomings to be seriously considered
as a means of communication."   Western Union internal memo, 1876.

"Heavier-than-air flying machines are impossible."
Lord Kelvin, president, Royal Society, 1895.

"Everything that can be invented has been invented."
Charles H. Duell, Commissioner, U.S. Office of Patents, 1899.

Re: C is 'better' than Ada because...

[David Weller]

In article <JSA.96Aug15152839@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>[Regarding a comment about the dearth of Ada 95 books in the public
market.]
>A chicken or egg problem if there ever was one.  Bookstore managers
>are some of the most fad/pop oriented folks around (for obvious
>reasons).  So, the only way to change this would be for more people to
>actually request one or more of the many good books available but not
>readily so from your local general book store.
>

The "du jour" effect is easily seen.  I did an inventory today during
my weekly pilgrimage to Barnes & Noble here in the DFW area.  Java
books outnumber C++ books by a 2:1 ratio!  Visual Basic is on par with
C++.  Other "esoteric" languages: LISP, Ada 95, Smalltalk, etc. are
few and far between.

About the only thing one can judge from their inventory is what is
selling, not what language is better (or worse!).  I could quickly
judge that COBOL is a dead language, based on the two books I saw
there.  I'd hardly call COBOL dead!

-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: C is 'better' than Ada because...

[William C Brennan]

In article <4v0l3i$l0d@dfw.dfw.net>, dweller@dfw.net (David Weller) wrote:
> About the only thing one can judge from their inventory is what is
> selling, not what language is better (or worse!).  I could quickly
> judge that COBOL is a dead language, based on the two books I saw
> there.  I'd hardly call COBOL dead!

Nahh, it's only restin'.  Pinin' for the fiords.

-- 
Bill Brennan
brennanw@pond.com

Re: C is 'better' than Ada because...

[Robert Dewar]

Kevin says

"I do the same in C.  The problem is that Ada won't *let* you use your superior
skill, i.e., nothing is gained by it.  For someone who knows what they're
doing, it's just as easy to write good, clean, safe code in C (or assembly, or
*any* language) as it is in Ada."

Maybe you have superior skill as a C coder, but clearly you know nothing
about Ada to make such a clearly incorrect statement. Please give a single
example that backs up your claim. As for the idea that it is just as
easy to write good, clean, safe code in assembler as in a high level
lanvguage -- that is clearly also nonsense, and here is extensive data
to establish that this is more than just a matter of subjective opinion.

Of course you could always claim to be the only person that knows what
they are doing, and then refuse to demonstrate that you don't :-)

Re: C is 'better' than Ada because...

[John F. Bode]

In article <31e02c32.342948604@netline-fddi.jpl.nasa.gov> Kevin D. Quitt,
kdq@emoryi.jpl.nasa.gov writes:
>I do the same in C.  The problem is that Ada won't *let* you use your superior
>skill, i.e., nothing is gained by it.  For someone who knows what they're
>doing, it's just as easy to write good, clean, safe code in C (or assembly, or
>*any* language) as it is in Ada.
>

Ada certainly won't let you multiply 'A' by 1.34 and use that to index an
array, at least not without jumping through a lot of hoops, but this bit
about "not letting you use your superior skill" is hogwash.  A lot of
what is considered "superior skill" and "programmer freedom" in C is
really poor programming practice (I know, most professional C programmers
follow good practice, but you have to admit, that's in *spite* of C, not
because of it).  

The point is, you may be able to write good, clean, safe code in C.  You
may be able to write good, clean, safe code in FORTRAN, or COBOL, or
Pascal, or BASIC, or assembler.  But you can't really *know* that it's
good, clean, safe code until the testing phase, which is usually the
phase that gets cut short because of budget or schedule slips.  By being
so picky, Ada forces you to write good, clean, safe code AS YOU ARE
DEVELOPING IT.  

What is considered C's greatest asset is also its greatest failing for
developing large, robust systems: it assumes that you, the programmer,
know what you are doing at all times.  That's a bad assumption to make
for a lot of us (me included).  

John F. Bode
representing nobody but myself...

Re: C is 'better' than Ada because...

[Mike Roske]

John F. Bode wrote:
> 
> In article <31e02c32.342948604@netline-fddi.jpl.nasa.gov> Kevin D. Quitt,
> kdq@emoryi.jpl.nasa.gov writes:
> >I do the same in C.  The problem is that Ada won't *let* you use your superior
> >skill, i.e., nothing is gained by it.  For someone who knows what they're
> >doing, it's just as easy to write good, clean, safe code in C (or assembly, or
> >*any* language) as it is in Ada.
> The point is, you may be able to write good, clean, safe code in C.  You
> may be able to write good, clean, safe code in FORTRAN, or COBOL, or
> Pascal, or BASIC, or assembler.  But you can't really *know* that it's
> good, clean, safe code until the testing phase, which is usually the
> phase that gets cut short because of budget or schedule slips.  By being
> so picky, Ada forces you to write good, clean, safe code AS YOU ARE
> DEVELOPING IT.
> 
> What is considered C's greatest asset is also its greatest failing for
> developing large, robust systems: it assumes that you, the programmer,
> know what you are doing at all times.  That's a bad assumption to make
> for a lot of us (me included).

I have to disagree a little bit here.  I don't believe Ada FORCES you to
write good, clean, safe code.  It just makes certain bad things more
difficult to accomplish.  Having had the experience of guiding
(shepherding? ;-)  ) several 'C' code writers into writing more
structured software, I can tell you that it is just as easy to write
bad, dirty, dangerous code in Ada.  And we didn't really *know* it was
dirty and dangerous until the testing phase.  It met all of the Ada
guidelines and STILL corrupted memory (bad pointer allocation).

Bottom line:  ENGINEERS who know how to build STRUCTURED SOFTWARE will
do so no matter what the language.  CODERS who only know the syntax will
have problems no matter what the language.

Also speaking for myself,
Mike Roske

Re: C is 'better' than Ada because...

[Peter Hermann]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: Kevin says

: "I do the same in C.  The problem is that Ada won't *let* you use your superior
: skill, i.e., nothing is gained by it.  For someone who knows what they're
: doing, it's just as easy to write good, clean, safe code in C (or assembly, or
: *any* language) as it is in Ada."

: Maybe you have superior skill as a C coder, but clearly you know nothing
: about Ada to make such a clearly incorrect statement. Please give a single
: example that backs up your claim. As for the idea that it is just as
: easy to write good, clean, safe code in assembler as in a high level
: lanvguage -- that is clearly also nonsense, and here is extensive data
: to establish that this is more than just a matter of subjective opinion.

: Of course you could always claim to be the only person that knows what
: they are doing, and then refuse to demonstrate that you don't :-)

bingo!

Kevin,
I intentionally repeated the above statements of Robert in full length
because I fully agree with every single word.
Please note, Kevin, that Robert was extremely polite and diplomatic
in your case, more than you deserve.
In order to keep the level of behavior in comp.lang.ada high
I will control myself, too.
I hope you are able to read in-between the lines.   :-|

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: C is 'better' than Ada because...

[Tim McGuire]

If assembly is just as easy as high-level languages, why were high-level
languages created???

> Robert Dewar (dewar@cs.nyu.edu) wrote:
> : Kevin says
> 
> : "I do the same in C.  The problem is that Ada won't *let* you use your superior
> : skill, i.e., nothing is gained by it.  For someone who knows what they're
> : doing, it's just as easy to write good, clean, safe code in C (or assembly, or
> : *any* language) as it is in Ada."
> 
> : Maybe you have superior skill as a C coder, but clearly you know nothing
> : about Ada to make such a clearly incorrect statement. Please give a single
> : example that backs up your claim. As for the idea that it is just as
> : easy to write good, clean, safe code in assembler as in a high level
> : lanvguage -- that is clearly also nonsense, and here is extensive data
> : to establish that this is more than just a matter of subjective opinion.
> 
> : Of course you could always claim to be the only person that knows what
> : they are doing, and then refuse to demonstrate that you don't :-)
> 
> bingo!
> 
> Kevin,
> I intentionally repeated the above statements of Robert in full length
> because I fully agree with every single word.
> Please note, Kevin, that Robert was extremely polite and diplomatic
> in your case, more than you deserve.
> In order to keep the level of behavior in comp.lang.ada high
> I will control myself, too.
> I hope you are able to read in-between the lines.   :-|
> 
> --
> Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
> Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
> Team Ada: "C'mon people let the world begin" (Paul McCartney)
> 
> 

                               \^^^^^^^^/
                                (.)  (.)
--------------------------.oooO-- (__) --Oooo.----------------------------

 !         ________         /`|`\   +------------------------------------+
 ! _....._/|__|____\..___../  | |   | Tim McGuire                        |
<|~oooo   _____            c===-|---+ tmcguire@superior.net              |
 !\...___/~~~~~\_____..___---.|,/   | http://www.superior.net/~tmcguire/ |
 !       / |~~|__..-`   0           +------------------------------------+
        <  |        		    "I believe it's time for me to fly..."
         (o)				-REO Speedwagon

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On Mon, 15 Jul 1996 12:19:02 -0400, Tim McGuire <tmcguire@superior.net> wrote:

>If assembly is just as easy as high-level languages, why were high-level
>languages created???

Because the number of lines of code per day per programmer is fairly constant
regardless of language.  Using high-level languages allows programmer to
produce more software in a given period.

What I said is that it's as easy to write high-quality software in assembler
as it is in any language.  It's not the language that's the problem.  It's the
programmer.  A high-quality programmer will turn out high-quality code
regardless of the language, and a poor programmer will turn out poor quality
code no matter how hard the language tries to prevent him.

It's a matter of choice, I suppose.  Some people like their language to
protect them, I don't.  I believe that a protective language can lead to
sloppier code because the programmer comes to trust the compiler to catch
sloppy mistakes; I've seen it happen.  That's why I prefer spectacular
failures (e.g., core dumps) to quiet ones (error message on exit that the
program erroneously wrote on memory).

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Robert Dewar]

Kevin said

"What I said is that it's as easy to write high-quality software in assembler
as it is in any language.  It's not the language that's the problem.  It's the
programmer.  A high-quality programmer will turn out high-quality code
regardless of the language, and a poor programmer will turn out poor quality
code no matter how hard the language tries to prevent him."

This is in my experience (which incidentally includes having written at
least half a million lines of delivered commercial assembly language,
and more than half a million lines of dlivered commercial code in high
level languages, in case you think I am talking from the ivorty tower)
complete and utter nonsense. 

It is FAR harder to write in assembler than it is in a well designed
higher level language. There are several reasons.

  Redundancy, e.g. strong type checking, allows mistakes to be found by
  the compiler that otherwise have to be found by tedious testing (nothing
  in assembler stops you doing an integer add on floating point numbers by
  accident).

  Baroque and peculiar semantic environments. Almost all machines, even
  most RISC machines have odd corners and irregularities that intefere
  with clean design.

  Having to remember the contents of a register file is a big burden. It
  is as though you were forced to name your variables silly short names
  in a high level language and then alias them desperately.

  etc.  many more reasons

In my experience anyone who thinks this is true is unlikely to be generaing
high quality software in *either* assembler *or* in a high level language,
since that is really the only circumstance under which the claim of "it's
equally easy for me" could possibly be true.

I have had the misfortune true of trying to read poorly written Ada code,
but it is nothing compared to the much greater misfortune of trying to
read poorly written assembler code!

Re: C is 'better' than Ada because...

[Bob Gilbert]

In article <31ebfbd7.330061022@netline-fddi.jpl.nasa.gov>, kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes:
> On Mon, 15 Jul 1996 12:19:02 -0400, Tim McGuire <tmcguire@superior.net> wrote:
> 
> >If assembly is just as easy as high-level languages, why were high-level
> >languages created???
> 
> Because the number of lines of code per day per programmer is fairly constant
> regardless of language.  Using high-level languages allows programmer to
> produce more software in a given period.

Productivity is only one issue.  One must also consider portability and
readability.

Code written in a HOL can be (for the most part) simply recompiled for a
different target.  Assembly would require a complete rewrite.  

Code written in a HOL is generally easier to read (by both programmers and
non-programmers).  HOL's, such as Ada, consider self documenting features 
in their design.  Ada is good enough in this aspect than many times it is
considered acceptable to use as PDL for documenting the preliminary design, 
and the subsequent code (with some specific guidelines enforced) may many 
times be submitted for the final design.  Assembly code pretty much
requires a significant amount of supporting documentation be generated in
addition to the code.

-Bob

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On 18 Jul 1996 15:22:31 GMT, rgilbert@unconfigured.xvnews.domain (Bob Gilbert)
wrote:
>Productivity is only one issue.  One must also consider portability and
>readability.

The main reasons to avoid assembly language, especially the latter.  In some
senses, it's more important for a program to be readable/maintainable than to
actually work.

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Ken Garlington]

Kevin D. Quitt wrote:
> 
> It's a matter of choice, I suppose.  Some people like their language to
> protect them, I don't.  I believe that a protective language can lead to
> sloppier code because the programmer comes to trust the compiler to catch
> sloppy mistakes; I've seen it happen.  That's why I prefer spectacular
> failures (e.g., core dumps) to quiet ones (error message on exit that the
> program erroneously wrote on memory).

This would seem to imply that you like environments that generate "spectacular
failures" (e.g., exceptions) to quiet ones (subtle and random output
differences) for "sloppy" code that has invalid pointer references, etc.
True?

-- 
LMTAS - "Our Brand Means Quality"

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On Thu, 18 Jul 1996 11:02:41 +0000, Ken Garlington
<garlingtonke@lfwc.lockheed.com> wrote:
>This would seem to imply that you like environments that generate "spectacular
>failures" (e.g., exceptions) to quiet ones (subtle and random output
>differences) for "sloppy" code that has invalid pointer references, etc.
>True?

Essentially, yes.  I prefer an environment that doesn't make it easy for code
to work by accident.

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Richard O'Rourke]

In article <31efe069.63062188@netline-fddi.jpl.nasa.gov>,
Kevin D. Quitt <kdq@emoryi.jpl.nasa.gov> wrote:
>On Thu, 18 Jul 1996 11:02:41 +0000, Ken Garlington
><garlingtonke@lfwc.lockheed.com> wrote:

<<snip snip.....>>

>>failures" (e.g., exceptions) to quiet ones (subtle and random output
>>differences) for "sloppy" code that has invalid pointer references, etc.
>>True?
>
>Essentially, yes.  I prefer an environment that doesn't make it easy for code
>to work by accident.
>

AHA! Exactly what Ada gives you and C does NOT!.

>-- 
>#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
> _
>Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
>Per the FCA, this email address may not be added to any commercial mail list

--
Richard O'Rourke rorou@dev.hcsd.hac.ca
-- 
--
Richard O'Rourke rorou@dev.hcsd.hac.ca

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On 19 Jul 1996 13:02:33 -0700, rorou@itfhps00.itf.hcsd.ca (Richard O'Rourke)
wrote:

>>Essentially, yes.  I prefer an environment that doesn't make it easy for code
>>to work by accident.
>
>AHA! Exactly what Ada gives you and C does NOT!.

An environment, not a language.  The tools available do a sufficient job for
me.

Let me back off one thing, though.  I don't mean to say that C is "superior"
to ADA; I'd have to be an expert at both, not just one to actually have an
opinion.  What I mean is that I like C, and I don't like ADA; so for me, C is
"better".

(BTW, I just wrote the embedded code for the Telemetry Control Unit on the
Cassini Spacecraft, in C of course, in well under 8K or ROM.  Is it possible
to generate a stand-alone ADA program that will run in that space?)

I'll further point out that on the Cassini craft, from all I've heard, the
software developed in ADA is behind schedule and functionally deficient.

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Robert Dewar]

Kevin said

"Let me back off one thing, though.  I don't mean to say that C is "superior"
to ADA; I'd have to be an expert at both, not just one to actually have an
opinion.  What I mean is that I like C, and I don't like ADA; so for me, C is
"better"."

Yes, but you don't know Ada (not even how to spell the name of the language!)
as has been clear from your previous posts. You probably also don't like
COBOL and know nothing about it.

It would be one thing to say "I know and like C, and I don't know Ada, so
for me, C is 'better'", but I think it is safer not to take a dislike
to languages you don't know (althought that certainly is common -- hands
up now all those who are sure they don't like COBOL without knowing
a thing about it :-)

Re: C is 'better' than Ada because...

[Tim Behrendsen]

Robert Dewar <dewar@cs.nyu.edu> wrote in article
<dewar.838069989@schonberg>...
> Kevin said
> 
> "Let me back off one thing, though.  I don't mean to say that C is
"superior"
> to ADA; I'd have to be an expert at both, not just one to actually have
an
> opinion.  What I mean is that I like C, and I don't like ADA; so for me,
C is
> "better"."
> 
> Yes, but you don't know Ada (not even how to spell the name of the
language!)
> as has been clear from your previous posts. You probably also don't like
> COBOL and know nothing about it.
> 
> It would be one thing to say "I know and like C, and I don't know Ada, so
> for me, C is 'better'", but I think it is safer not to take a dislike
> to languages you don't know (althought that certainly is common -- hands
> up now all those who are sure they don't like COBOL without knowing
> a thing about it :-)

I am totally ignorant of Ada, except for a book I flipped through a
long time ago.  I use C, because it has the most infrastructure along
with it, including programming talent.  I'm in business to make money,
not to push back the frontiers of computer science (the pioneers take
the arrows).

My personal preference is for small nuts-and-bolts languages, anyway.
Ada always seemed too "kitchen sink" for my tastes.

My question is this, and I really don't mean this snidely: If Ada is so
good, why are the only companies that use it are the ones that deal with
the government, which make them use it?  Ada has had plenty of time to
develop the infrastructure that C has developed, so it can't be a "I
don't want to be first" mentality on the part of industry.

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[Theodore E. Dennison]

Tim Behrendsen wrote:
> 
> My personal preference is for small nuts-and-bolts languages, anyway.
> Ada always seemed too "kitchen sink" for my tastes.

Mine is for languages that are the least error prone, and the easiest 
to track down bugs in. That way, I get to spend my evenings at home
with my family.

> My question is this, and I really don't mean this snidely: If Ada is so
> good, why are the only companies that use it are the ones that deal with
> the government, which make them use it?  Ada has had plenty of time to
> develop the infrastructure that C has developed, so it can't be a "I
> don't want to be first" mentality on the part of industry.

You have a good point. Unfortunately, your premise is wrong. Ada is in 
extensive use outside of the Government. In fact it is the language of 
choice wherever a software failure is liable to cause loss of life or a 
very large lawsuit. 

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: C is 'better' than Ada because...

[Tim Behrendsen]

Theodore E. Dennison <dennison@escmail.orl.mmc.com> wrote in article
<31F613F3.2781E494@escmail.orl.mmc.com>...
> Tim Behrendsen wrote:
> > 
> > My personal preference is for small nuts-and-bolts languages, anyway.
> > Ada always seemed too "kitchen sink" for my tastes.
> 
> Mine is for languages that are the least error prone, and the easiest 
> to track down bugs in. That way, I get to spend my evenings at home
> with my family.
> 
> > My question is this, and I really don't mean this snidely: If Ada is so
> > good, why are the only companies that use it are the ones that deal
with
> > the government, which make them use it?  Ada has had plenty of time to
> > develop the infrastructure that C has developed, so it can't be a "I
> > don't want to be first" mentality on the part of industry.
> 
> You have a good point. Unfortunately, your premise is wrong. Ada is in 
> extensive use outside of the Government. In fact it is the language of 
> choice wherever a software failure is liable to cause loss of life or a 
> very large lawsuit. 

This sounds to me like the "Macintosh" argument; if only the general
public weren't so ignorant, the Macintosh would be the dominant
platform.  Never mind the very real problems with the platform.

Based on your post, Ada is only appropriate for mission critical
applications, and not for other applications? Again, the question,
and I ask this respectfully, "If it's so good, why isn't it used more
universally than it is?"  And, if C is so bad (in many people's opinion,
not mine), why is it used almost universally, despite its acknowledged,
real problems?

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[Dirk Dickmanns]

"Tim Behrendsen" <tim@airshields.com> writes:

>This sounds to me like the "Macintosh" argument; if only the general
>public weren't so ignorant, the Macintosh would be the dominant
>platform.  Never mind the very real problems with the platform.

True for both Ada and Mac (and cheapish workstations):
Yes, it has problems, but it has a quite clean
architecture -- sadly enough most won't use it
due to conventional reasons.

>Again, the question,
>and I ask this respectfully, "If it's so good, why isn't it used more
>universally than it is?"  And, if C is so bad (in many people's opinion,
>not mine), why is it used almost universally, despite its acknowledged,
>real problems?

I posted five reasons from an earlier post of yours, I'll add some
now:

Not willing to invest conversion cost -- return of investment could
take more than a single project.

General unwillingness to change -- it takes personal effort to fight
the intricacies of other languages.

There is neither a Borland Ada for Windoze nor a Visual Ada from
Mickey$oft.

Everybody else uses C.

And again: Not knowing Ada.


For the record:
I had the usual history: BASIC, Pascal, Assembler (8086), Prolog,
Lisp, OO-Pascal, C, C++. Then less usual: occam, Eiffel3, Ada95,
Python, Caml. For my work in computer vision, Ada95 is by far the
favorite, which does not mean I wouldn't use anything else, if
appropriate. But this rarely occurs, most of my new software is Ada
and even some of the old will be converted for maintenance reasons and
ease of use. Most of the old is accessed via bindings, though.


>-- Tim Behrendsen (tim@airshields.com)

I wouldn't choose a domain so closely named to airheads.com !-)

Dirk

--
Dirk Dickmanns -- REALIS -- real-time dynamic computer vision
Sun OS 4.1.3; PC Linux; Ada, OCCAM, C, Eiffel, PROLOG, C++

Re: C is 'better' than Ada because...

[Tim Behrendsen]

Dirk Dickmanns <dirk@hera.informatik.unibw-muenchen.de> wrote in article
<dirk.838639294@hera>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> >Again, the question,
> >and I ask this respectfully, "If it's so good, why isn't it used more
> >universally than it is?"  And, if C is so bad (in many people's opinion,
> >not mine), why is it used almost universally, despite its acknowledged,
> >real problems?
> 
> I posted five reasons from an earlier post of yours, I'll add some
> now:

Sorry -- I thought you were joking before.

> Not willing to invest conversion cost -- return of investment could
> take more than a single project.

> General unwillingness to change -- it takes personal effort to fight
> the intricacies of other languages.

> Everybody else uses C.
 
> And again: Not knowing Ada.
 
Same answer for the four of these ...

Ada has been around long enough to where if it gave real benefits,
some bright people would have made the investment to pave the way.
It just hasn't happened.  People have poured endless money into C++,
Java, etc.  Again, why?  It's used all over the place in Aerospace
(That was kind of catchy ... maybe that should be the Ada
slogan ;-> ).  You would think there would be some crossover
somewhere.

> There is neither a Borland Ada for Windoze nor a Visual Ada from
> Mickey$oft.

Again, why?  There are endless companies producing C++ compilers,
Pascal compilers, Java compilers, Modula III compilers for god's
sake, why not Ada?

> >-- Tim Behrendsen (tim@airshields.com)
> 
> I wouldn't choose a domain so closely named to airheads.com !-)

Well, it sort of chose me ... my company was bought out by
them. :)

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[whiting_ms@corning.com (Matt Whiting)]

In article <01bb7da5$ef97cf00$96ee6fcf@timhome2>, "Tim Behrendsen" <tim@airshields.com> writes:
> Dirk Dickmanns <dirk@hera.informatik.unibw-muenchen.de> wrote in article
> <dirk.838639294@hera>...
>
> {stuff deleted, but hopefully I kept the attributions lined up correctly!}
> 
>> There is neither a Borland Ada for Windoze nor a Visual Ada from
>> Mickey$oft.
> 
> Again, why?  There are endless companies producing C++ compilers,
> Pascal compilers, Java compilers, Modula III compilers for god's
> sake, why not Ada?
-- 

That's easy: neither Borland nor Microsoft make their money from selling high
quality, reliable software.  They make their money from selling inexpensive
(cheap) software that is "good enough" (the 80/20 rule) for desktop users who
will tolerate an occasional GPF and loss of a spreadsheet or letter.  People
tend to be less tolerant of failures in software that controls the airplane
they are flying on...

I know analogy is a weak and dangerous form of argument, but this reminds me of
the aspirin vs. neurosurgeon scenario.  Why are there more people that sell
aspirin than they are that perform brain surgery?  Simple, most headaches don't
REQUIRE brain surgery and aspirin is an adequate solution.  However, if you
really NEED brain surgery, aspirin isn't a great choice.  You decide which
object in the above scenario is C and which is Ada.  Using the above argument,
I'd say that neurosurgeons are inferior to aspirin sellers as they aren't
nearly as readily available nor as cheap.

-------------------------------------------------------------------------------
Matthew S. Whiting, P.E.         | Corning Incorporated | (607) 974-6317 phone
Manager Advanced Control Systems | HP-ME-01-034         | (607) 974-6752 fax
whiting_ms@corning.com           | Corning, NY 14831    |

Re: C is 'better' than Ada because...

[Dirk Dickmanns]

"Tim Behrendsen" <tim@airshields.com> writes:

>Dirk Dickmanns <dirk@hera.informatik.unibw-muenchen.de> wrote

>> I posted five reasons from an earlier post of yours, I'll add some
>> now:

>Sorry -- I thought you were joking before.

No! You just had them right!

<circular junk from both deleted>

Many others posted similar reasons for Ada not taking off. Technical
merit is of no concern on that matter. What made me looking at Ada was
the extreme commitment to Ada of people using C before... think about
it. I am just beginning to profit from choosing Ada over C :-)

Dirk

--
Dirk Dickmanns -- REALIS -- real-time dynamic computer vision
Sun OS 4.1.3; PC Linux; Ada, OCCAM, C, Eiffel, PROLOG, C++

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On 31 Jul 96 10:36:37 GMT, dirk@hera.informatik.unibw-muenchen.de (Dirk
Dickmanns) wrote:

>What made me looking at Ada was
>the extreme commitment to Ada of people using C before... think about
>it.

Curious.  It's that's same commitment to C from former Ada programmers that
makes me so leery of Ada.  Especially since these are all people whom I
consider to be good programmers (not a distinction I give lightly).

-- 
#include <standard_disclaimer.h>
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Alan Brain]

kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) wrote:

>Curious.  It's that's same commitment to C from former Ada programmers that
>makes me so leery of Ada.  Especially since these are all people whom I
>consider to be good programmers (not a distinction I give lightly).

Really? I'm flabbergasted. In 15 years I've never met a single person who, after 
programming in Ada for more than 6 months, preferred programming in C. I've met 
people who dabbled in Ada, didn't like it; and people who just couldn't handle data 
abstraction and programming-in-the-large. But never anyone who was taught to use it, 
practiced using it.

The original poster is in Germany, and a lot of my experience ( about half ) 
occurred there, at SystemTeknikNord and Atlas Elektronik GmbH.
 

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On 1 Aug 1996 16:17:36 GMT, Alan Brain <aebrain@dynamite.com.au> wrote:

>kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) wrote:
>
>>Curious.  It's that's same commitment to C from former Ada programmers that
>>makes me so leery of Ada.
>Really? I'm flabbergasted. In 15 years I've never met a single person who, after 
>programming in Ada for more than 6 months, preferred programming in C.

We must live on opposite sides of the mirror.  There's one in my office, one
next door, and several down the hall.  Some of these people changed divisions
to get away from Ada (after finishing a large project).

-- 
#include <standard_disclaimer.h>
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Byron B. Kauffman]

Kevin D. Quitt wrote:
> 
snip...
> 
> We must live on opposite sides of the mirror.  There's one in my office, one
> next door, and several down the hall.  Some of these people changed divisions
> to get away from Ada (after finishing a large project).
> 

You know what they say about 'birds of a feather'...

Byron Kauffman
LMTAS

Re: C is 'better' than Ada because...

[Mike Roske]

Alan Brain wrote:
> Really? I'm flabbergasted. In 15 years I've never met a single person who, after
> programming in Ada for more than 6 months, preferred programming in C.

Glad to meet you.  I've developed many thousands of lines of C and
Ada83 and actually prefer C.  Ok, most of that experience has been in 
small (35K-75K SLOC) embedded systems without MAJOR safety requirements,
and that may make a difference.  And I haven't yet taken a close look at
Ada95, and that may make a difference too.

I understand Ada, and all of the data abstractions and structure it
enforces.  However, as a software engineer who believes in structured
development (in any language), I find Ada too restrictive.  Many 
implementations help in this, providing add-on packages for things
like C-type strings (useful for interfacing with many OS calls).
However, the language does not readily provide for some constructs I
have found very useful, such as pointers to subprograms, and assigning a
pointer to an existing object.  (yes, both can be done, but not as
easily as in C).

I also continually fight an issue that was mentioned earlier: size.
Most of my projects have been PROM limited in executable size.  I have
found that most C compilers generate tighter, better optimized code.
The added checking that Ada compilers provide before and after each
subprogram call and assignment is unnecessary in many cases.
Admittedly, this is more of an implementation issue.  There must be some
Ada compilers that optimize well, but I haven't yet had the pleasure
of using them.

IMHO, C is a "better" language when structured development is used.

-- 
*-------------------------------------------------------*
* Michael Roske
* Sanders, A Lockheed Martin Company
* mroske@mailgw.sanders.lockheed.com
* (603) 885-9240
*-------------------------------------------------------*
* "I'd rather be flying RC..."                     
*-------------------------------------------------------*

Re: C is 'better' than Ada because...

[David Shochat]

Mike Roske wrote:
[snip]
> Many 
> implementations help in this, providing add-on packages for things
> like C-type strings (useful for interfacing with many OS calls).
> 
All taken care of in Ada 95 by Interfaces.C and Interfaces.C.Strings,
which are standard.

> However, the language does not readily provide for some constructs I
> have found very useful, such as pointers to subprograms, and assigning a
> pointer to an existing object.  (yes, both can be done, but not as
> easily as in C).
> 
Both can be done very easily in Ada 95.

> I also continually fight an issue that was mentioned earlier: size.
> Most of my projects have been PROM limited in executable size.  I have
> found that most C compilers generate tighter, better optimized code.
> The added checking that Ada compilers provide before and after each
> subprogram call and assignment is unnecessary in many cases.

If the added safety is not worth the cost for you, you can choose to
suppress the checks.

> Admittedly, this is more of an implementation issue.  There must be some
> Ada compilers that optimize well, but I haven't yet had the pleasure
> of using them.
> 
Obviously, you haven't had the pleasure of using GNAT:
ftp://cs.nyu.edu/pub/gnat
And with GNAT, you have an excellent compiler for your current favorite
language as well as Ada 95, in the same attractive package.

-- David

Re: C is 'better' than Ada because...

[Ken Garlington]

David Shochat wrote:
> 
> > I also continually fight an issue that was mentioned earlier: size.
> > Most of my projects have been PROM limited in executable size.  I have
> > found that most C compilers generate tighter, better optimized code.
> > The added checking that Ada compilers provide before and after each
> > subprogram call and assignment is unnecessary in many cases.
> 
> If the added safety is not worth the cost for you, you can choose to
> suppress the checks.

It should also be pointed out that, even with checks _not_ suppressed, no
Ada compiler I've ever used for embedded systems work does a check "before
and after each subprogram call and assignment." If it did, I would consider
it unsuitable for such work! The technoology for optimizing checks has been
around for many years now.

I would be interested to see some hard evidence that most C compilers for
PROM-limited targets significantly outperform Ada compilers for the same
targets, given equivalent applications (same level of run-time checking,
equivalent algorithms, etc.) I do know that Tartan has released data for
their DSP Ada compilers showing them to be quite competitive with respect
to executable size.

-- 
LMTAS - "Our Brand Means Quality"

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <4v14u7$hkl@newsbf02.news.aol.com> johnherro@aol.com (John Herro) writes:

>      Ada *IS* more restrictive, but the restrictions help prevent
> errors.  In Ada you *cannot* produce a dangling reference, unless
> you deliberately use Unchecked_Access or Unchecked_Deallocation.
                                           ^^^^^^^^^^^^^^^^^^^^^^
Well, without GC, it is highly likely you are going to be using UD (or
not using the heap or leaking).  Sure, there are cases where user
defined finalization will greatly localize the use of UD and prevent
errors of its omission.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[John Herro]

Mike Roske <mroske@mailgw.sanders.lockheed.com> writes:
> [Ada] does not readily provide for... pointers
> to subprograms, and assigning a pointer to
> an existing object. ...  I haven't yet taken a
> close look at Ada95.
     Ada 95 lets you do both of these easily.  However, IMO it's easy to
overuse these features, especially assigning a pointer to an existing
object.
     In Ada 83, either the pointer or the object pointed to has a name,
but not both.  That's adequate for most purposes.
     However, assigning a pointer to an existing object is useful for
interfacing to C programs, and for creating linked lists and trees without
dynamically allocating memory.  (I got that from RENDEZVOUS WITH ADA 95,
by David Naiditch, p. 398.)
     You'll find that there's much less need for pointers in Ada than
there is in C.  I think that's a good thing, because pointers tend to be
error prone.
> I find Ada too restrictive.
     Ada *IS* more restrictive, but the restrictions help prevent errors. 
In Ada you *cannot* produce a dangling reference, unless you deliberately
use Unchecked_Access or Unchecked_Deallocation.
> The added checking that Ada compilers provide
> before and after each subprogram call and
> assignment is unnecessary in many cases.
     Again, this is to help prevent errors, but the checking can be turned
off when and where this is desired.
- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor

Re: C is 'better' than Ada because...

[John Herro]

I wrote:
> In Ada 83, either the pointer or the object
> pointed to has a name, but not both.
     I wrote that too hastily!  I meant to say that in Ada 83, the pointer
has a name, but the object pointed to doesn't.  Nothing can point to
objects that have names in Ada 83.  This, of course, changed with Ada 95.
- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor

Re: C is 'better' than Ada because...

[Robb Nebbe]

Kevin D. Quitt wrote:
> 
> On 31 Jul 96 10:36:37 GMT, dirk@hera.informatik.unibw-muenchen.de (Dirk
> Dickmanns) wrote:
> 
> >What made me looking at Ada was
> >the extreme commitment to Ada of people using C before... think about
> >it.
> 
> Curious.  It's that's same commitment to C from former Ada programmers that
> makes me so leery of Ada.  Especially since these are all people whom I
> consider to be good programmers (not a distinction I give lightly).

I've seen the same situation with Fortran and C. A very good Fortran
programmer is forced to use C for a while. They never attain anywhere
near the mastery of C that they had of Fortran and then they go
running back to Fortran at the first opportunity. 

There are two problems here. They were forced to use another language 
which tends to color people's perception and they were never in a
position where they could actually make a rational decision between the
two languages because they knew one language much better than the other.

Robb Nebbe

Re: C is 'better' than Ada because...

[Dirk Dickmanns]

in comp.lang.religious-wars

kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes:

>On 31 Jul 96 10:36:37 GMT, dirk@hera.informatik.unibw-muenchen.de (Dirk
>Dickmanns) wrote:

>>What made me looking at Ada was
>>the extreme commitment to Ada of people using C before... think about
>>it.

>Curious.  It's that's same commitment to C from former Ada programmers that
>makes me so leery of Ada.  Especially since these are all people whom I
>consider to be good programmers (not a distinction I give lightly).

>Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up

So our statistics are made up in different ways ;-)
I not yet met the people you are talking about.

Dirk

--
Dirk Dickmanns -- REALIS -- real-time dynamic computer vision
Sun OS 4.1.3; PC Linux; Ada, OCCAM, C, Eiffel, PROLOG, C++

Re: C is 'better' than Ada because...

[Bob Kitzberger]

Tim Behrendsen (tim@airshields.com) wrote:

: > You have a good point. Unfortunately, your premise is wrong. Ada is in 
: > extensive use outside of the Government. In fact it is the language of 
: > choice wherever a software failure is liable to cause loss of life or a 
: > very large lawsuit. 

: Based on your post, Ada is only appropriate for mission critical
: applications, and not for other applications?

That does not follow from the poster's comments, does it?

: Again, the question,
: and I ask this respectfully, "If it's so good, why isn't it used more
: universally than it is?"  And, if C is so bad (in many people's opinion,
: not mine), why is it used almost universally, despite its acknowledged,
: real problems?

Do you really think that technological superiority is the sole
determinant of success in the marketplace?  Talk to the marketing
folks in your organization, and ask them about the effects of market
share.  And if you stop at McDonald's for lunch sometime, ask
yourself if that's really the best restaraunt on the planet (it
certainly is the most popular).

--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

Re: C is 'better' than Ada because...

[Tim Behrendsen]

Bob Kitzberger <rlk@rational.com> wrote in article
<4tiorn$r5b@rational.rational.com>...
> Tim Behrendsen (tim@airshields.com) wrote:
> 
> : > You have a good point. Unfortunately, your premise is wrong. Ada is
in 
> : > extensive use outside of the Government. In fact it is the language
of 
> : > choice wherever a software failure is liable to cause loss of life or
a 
> : > very large lawsuit. 
> 
> : Based on your post, Ada is only appropriate for mission critical
> : applications, and not for other applications?
> 
> That does not follow from the poster's comments, does it?

Sorry; this has been misinterpreted by two people, so let me
rephrase the sentence.

You say that it is the language of choice when software failure is
liable to cause loss of life or a very large lawsuit.  These
are very worthy attributes.  Given that this is the case, why
isn't it being used more universally for non-mission critical
software?

[and again, let me stress that this is not a "wise guy" question;
I am sincerely interested, since from everything I have heard,
albeit not seen for myself, Ada is a very good language]

-- Tim Behrendsen (tim@airshields)

Re: C is 'better' than Ada because...

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@airshields.com> writes:
>You say that it is the language of choice when software failure is
>liable to cause loss of life or a very large lawsuit.  These
>are very worthy attributes.  Given that this is the case, why
>isn't it being used more universally for non-mission critical
>software?

Speaking as someone who has used C for a long time, and is very happy
with Ada (despite feeling that a few aspects, which are already far
better than C, could have been better still), I would say that Ada is
a very usable language for all sorts of things.  It was very easy to
"get my feet wet" with Ada/Ed.  With GNAT (as cheap as gcc...) I am
very happy indeed.

What I *don't* understand is why people are puzzled by the fact that it
is hard to dislodge the first occupant of a niche.  (Not impossible, but
hard.)  Mammals didn't replace dinosaurs until after something else wiped
them out.  The only thing that could ever dislodge me from using MacWrite
on a Macintosh to the detestable Microsoft Word was the fact that the old
copy of MacWrite wouldn't run reliably on the latest system software and
the department wasn't about to buy a new copy for just one user.  Word
may have all sorts of extra features, but I already _knew_ MacWrite, had
a lot of documents in MacWrite format that I didn't want to convert, and
didn't see enough advantage in switching to justify learning a new word
processor _however_ good it might be.  (In fact, I'm not switching to
Weird, I'm switching to LaTeX, which I've already used on CMS, VMS, UNIX,
and DOS ...)

Similarly, I drive a 1975 car.  It still works.  I can't *afford* to
replace it with a new model, even if a new model is better.

Let me offer another example.  Suppose there were a programming language
which is simple, far more expressive and powerful than C, as efficient
as C, with a clean GUI library that has been designed so that programs
will be the *same* on UNIX-X, Windows, and Mac, in which type errors and
storage allocation errors and unintentional file overwriting errors and
so on were impossible, yet remained expressive and comfortable.  And
suppose that the implementation were free.

Do you suppose it would take the world by storm?
Well, _I_ use it, but no, Clean (for that is its name), has _not_ taken
the world by storm, and I don't expect it will.

Conversely, the students I've supervised who've used Microsoft Access
for projects tend to be mildly to *extremely* unhappy with the language
side of it, but that doesn't hurt it in the market, does it?

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: C is 'better' than Ada because...

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<4tkfqk$duc@goanna.cs.rmit.edu.au>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> >You say that it is the language of choice when software failure is
> >liable to cause loss of life or a very large lawsuit.  These
> >are very worthy attributes.  Given that this is the case, why
> >isn't it being used more universally for non-mission critical
> >software?
> 
> What I *don't* understand is why people are puzzled by the fact that it
> is hard to dislodge the first occupant of a niche.  (Not impossible, but

Hmmm ... that is a reasonable point, and when I started thinking about
it, C didn't get popular until the early 80s after almost 10-13 years
in existence. Ada was invented in 83 (was that the first version?), so
one could argue that Ada is on schedule to become popular, if it's going
to be.  Ada is so "under the radar" that it's hard to judge if its
popularity is increasing or not.

The other advantage C had was it was the language for the first
[popular] portable operating system, Unix.  This gave it a huge
advantage, since it captured the imagination of the "computer
underground" that gave the tool base a big boost.

Perhaps a better title for this thread is, "Why does *any* language
become popular?"

> Let me offer another example.  Suppose there were a programming language
> which is simple, far more expressive and powerful than C, as efficient
> as C, with a clean GUI library that has been designed so that programs
> will be the *same* on UNIX-X, Windows, and Mac, in which type errors and
> storage allocation errors and unintentional file overwriting errors and
> so on were impossible, yet remained expressive and comfortable.  And
> suppose that the implementation were free.

I would say that was hopelessly idealistic. :)

> Do you suppose it would take the world by storm?
> Well, _I_ use it, but no, Clean (for that is its name), has _not_ taken
> the world by storm, and I don't expect it will.

Never know; maybe you should write a free operating system in it. :)

> Conversely, the students I've supervised who've used Microsoft Access
> for projects tend to be mildly to *extremely* unhappy with the language
> side of it, but that doesn't hurt it in the market, does it?

It's amazing the vitriol that Microsoft can bring out.  I was just
reading a post somewhere else that this guy hated everything Microsoft
has ever done, but he really liked Access.  Sigh ...

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[Theodore E. Dennison]

Tim Behrendsen wrote:
> 
> You say that it is the language of choice when software failure is
> liable to cause loss of life or a very large lawsuit.  These
> are very worthy attributes.  Given that this is the case, why
> isn't it being used more universally for non-mission critical
> software?

Well, to aswer what you are asking, it IS used more universally.
(...than you appear to think it is).

That's what "language of choice" means.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Ada is 'better' than C because...

[John Herro]

"Tim Behrendsen" <tim@airshields.com> writes:
> If C is so bad (in many people's opinion,
> not mine), why is it used almost universally?
     Inertia!  Because it's effort to change!
     Why are we all using qwerty keyboards when we know that Dvorak is
better?  Inertia!  It would be a lot of effort to unlearn qwerty and learn
Dvorak!
     Why hasn't the U.S. switched to the metric system, which is obviously
much easier to work with?  Inertia!  The cost of changing!
     Why don't all the schools teach Esperanto as a second language, so
that anyone in the world could communicate with anyone?  Inertia!  The
difficulty of finding teachers for a relatively little-known language!
     Ada really *IS* an improvement over C.  C's biggest fault is that is
doesn't have procedures, only functions.  To modify calling parameters, C
has to use difficult-to-read and error-prone pointers, in a situation
where pointers shouldn't be necessary at all.
     C and qwerty are "used almost universally" because they're older and
are firmly established, even though both have been improved upon.
- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor
----------
MUSIC is easier to read when written in C.
SOFTWARE is easier to read when written in Ada.
----------

Re: Ada is 'better' than C because...

[Brian Rogoff]

johnherro@aol.com (John Herro) writes:
   "Tim Behrendsen" <tim@airshields.com> writes:
   > If C is so bad (in many people's opinion,
   > not mine), why is it used almost universally?
	Inertia!  Because it's effort to change!

But how did it become so popular that it could have inertia working on its 
side? Pascal appeared at roughly the same time, FORTH and PL/1 precede
it. 

	Why don't all the schools teach Esperanto as a second language, so
   that anyone in the world could communicate with anyone?  Inertia!  The
   difficulty of finding teachers for a relatively little-known language!

Besides, broken English is the de-facto Esperanto ;-).

	Ada really *IS* an improvement over C.  C's biggest fault is that is
   doesn't have procedures, only functions.  To modify calling parameters, C
   has to use difficult-to-read and error-prone pointers, in a situation
   where pointers shouldn't be necessary at all.

I agree that Ada is better than C, however, I have always been puzzled by the 
distinction in Ada between functions and procedures, which I view as an
unnecessary relic of Pascal. Why not just allow procedures which return 
things? Your complaint about C is more about its lack of parameter modes.

-- Brian

Re: Ada is 'better' than C because...

[Adam Beneschan]

rogoff@sccm.stanford.edu writes:

 >I agree that Ada is better than C, however, I have always been puzzled by the
 >distinction in Ada between functions and procedures, which I view as an
 >unnecessary relic of Pascal. Why not just allow procedures which return 
 >things? 

This question has, in the past, led to a religious war on
comp.lang.ada almost as great as "Which is the one true language?"  I
don't remember all the arguments on both sides.  However, I'd
recommend reading Bertrand Meyer's _Object-Oriented Software
Construction_, which makes a case for keeping the two concepts
separate.  Put simply, in Meyer's view, procedures tell an object to
DO SOMETHING, while functions ASK SOMETHING of an object.  Functions,
therefore, should be pure query operations that don't change anything
and will therefore return the same result if you call the function
several times in succession.  In Eiffel, Meyer's language, there is no
such thing as an IN or IN OUT parameter; procedures are not allowed to
return any values (but they may change the state of the object).

Even with this conceptual distinction, I suppose you could define both
"functions" and "value-returning procedures" in the language (as an
early Ada draft did).  However, they would appear syntactically
identical when you called the function or procedure, making it
non-obvious whether you're calling a function that does something
interesting on the side or not.

One last comment: one could also consider value-returning procedures
to be a "relic" of assembly language, in which you write a subroutine
that performs some action and returns a status value in the
accumulator register.  This is sort of how UNIX system calls strike me.

                                -- Adam


---
DWARF STABS ELF
Film at 11

Re: Ada is 'better' than C because...

[Franz Kruse]

rogoff@sccm.Stanford.EDU (Brian Rogoff) writes:

> 	Why don't all the schools teach Esperanto as a second language, so
>    that anyone in the world could communicate with anyone?  Inertia!  The
>    difficulty of finding teachers for a relatively little-known language!
>
> Besides, broken English is the de-facto Esperanto ;-).

Well, yes - to a fairly limited extent and the accent clearly being on BROKEN.
Don't let esperantists (I am one) hear that, they will feel sorry for you with
how little you are satisfied, compared to what you could have with ("unbroken")
Esperanto - not counting the enormous effort necessary to keep (and constantly
reproduce) this modest status quo (not for YOU, for us non-English speaking
countries only, of course).

Franz Kruse

Re: Ada is 'better' than C because...

[Richard Riehle]

The C family of languages is inherently dangerous.

A programming language for which pointer arithmetic is an essential
feature of non-trivial programs is not a language I want controlling
the systems where my life is on the line.   And, frankly, I don't care
how skilled the programmer is.  This is still an area where mistakes
occur all too frequently.

Richard Riehle

Re: Ada is 'better' than C because...

[Sandy McPherson]

Richard Riehle wrote:
> 
> The C family of languages is inherently dangerous.
> 
> A programming language for which pointer arithmetic is an essential
> feature of non-trivial programs is not a language I want controlling
> the systems where my life is on the line.   And, frankly, I don't care
> how skilled the programmer is.  This is still an area where mistakes
> occur all too frequently.
> 
> Richard Riehle

I have a view comments to make to your objective and considered
statements:

All programming languages are inherently dangerous, because they are
used by humans to write faulty software (see The Ariane debacle).

Since when was pointer arithmetic "essential"? It is simply convenient. 

I agree all programmers make mistakes, and too many of them. Intelligent
and workable coding standards need to be strictly applied in all
languages and tools must exist which can measure and report on
adherence/breach of the rules. The fact is that the primary tools (those
which you must use to get your program to run) for Ada are better than
those for C (e.g. the compiler, the APSE and the run-time system), but
some of the secondary tools for C can be better (e.g. QAC, Purify), the
problem being simply "you don't HAVE to use them", and you have to pay
extra for them (the (f)law of false economies). 

To get an objective view of whether one language is better than the
other, one has to evaluate statistics on error densities in comparable
systems written in the protagonist languages. Most people who have done
this come to this conclusion: the choice of programming language only
counts if the choice is between assembler and something else; and for
most mainstream higher languages the process of software development is
the determining factor. Try starting with a paper by Les Hutton, "Static
inspection - must have or might have?", published in IEEE software 1995,
which gives references to other interesting reading.

Sandy McPherson

Re: Ada is 'better' than C because...

[Ken Garlington]

Sandy McPherson wrote:
> 
> To get an objective view of whether one language is better than the
> other, one has to evaluate statistics on error densities in comparable
> systems written in the protagonist languages. Most people who have done
> this come to this conclusion: the choice of programming language only
> counts if the choice is between assembler and something else; and for
> most mainstream higher languages the process of software development is
> the determining factor. Try starting with a paper by Les Hutton, "Static
> inspection - must have or might have?", published in IEEE software 1995,
> which gives references to other interesting reading.

For a counter-example, see this study (which did evaluate error densities):

  http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html

From the summary:

"The choice of programming language is only one of many factors in project successes 
and failures. In our opinion, it is NOT the most important.... The language choice may 
only change expenses by a factor of two. Of course, a million dollars here and a 
million dollars there and pretty soon you're talking about real money."

So, although other factors such as software process may have a greater impact, at
least this study indicates that choice of programming language is a significant
issue. In this study, the same project done in C and Ada had significantly lower
error densities in the C version.

> 
> Sandy McPherson

-- 
LMTAS - "Our Brand Means Quality"

Re: Ada is 'better' than C because...

[GAFFNEY.BRIAN]

In article <320729F1.1ADC@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> writes...
>  http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html
..
>       In this study, the same project done in C and Ada had significantly 
>lower error densities in the C version.
 ^^^^^                        ^
I must have been reading a different article of the same name at the same site,
because I thought the result was just the opposite - C had _higher_ "error
densities" than Ada. 

Re: Ada is 'better' than C because...

[Ken Garlington]

GAFFNEY.BRIAN wrote:
> 
> In article <320729F1.1ADC@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> writes...
> >  http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html
> ..
> >       In this study, the same project done in C and Ada had significantly
> >lower error densities in the C version.
>  ^^^^^                        ^
> I must have been reading a different article of the same name at the same site,
> because I thought the result was just the opposite - C had _higher_ "error
> densities" than Ada.

Well, of course, it depends upon your definition of densities, and...

Oh, never mind. Of course I meant the Ada version had a lower error density than
the C version. People are just so picky...

-- 
LMTAS - "Our Brand Means Quality"

Re: Ada is 'better' than C because...

[Theodore E. Dennison]

Ken Garlington wrote:
> 
> For a counter-example, see this study (which did evaluate error densities):
>   http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html
...
> issue. In this study, the same project done in C and Ada had significantly lower
> error densities in the C version

Hmmm. I read the same study, but I thought the conclusion was the other way around;
unless my math is bad again. (Lower "error density" ==> less errors, right?)

The following was the heading on the conclusion -
   CONCLUSION: Development Costs of C Exceed Those of Ada

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Ada is 'better' than C because...

[Frank Lipski]

Theodore E. Dennison wrote:
> 
> Ken Garlington wrote:
> >
> > For a counter-example, see this study (which did evaluate error densities):
> >   http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html
> ...
> > issue. In this study, the same project done in C and Ada had significantly lower
> > error densities in the C version
> 
> Hmmm. I read the same study, but I thought the conclusion was the other way around;
> unless my math is bad again. (Lower "error density" ==> less errors, right?)
> 
> The following was the heading on the conclusion -
>    CONCLUSION: Development Costs of C Exceed Those of Ada
> 
> --
> T.E.D.
>                 |  Work - mailto:dennison@escmail.orl.mmc.com  |
>                 |  Home - mailto:dennison@iag.net              |
>                 |  URL  - http://www.iag.net/~dennison         |

   My reading of the report would agree with Ted's.  To summarize
  
defects/KSLOC  = 0.676 for C files and 0.096 for Ada files
-- 
----------------------------------------------------------------------
Standard Disclaimer applies.
      Frank Lipski   lipski@cs.lmco.com          770-494-8322
"The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" ("I found it!") but rather "hmm....that's
funny..."  --   Isaac Asimov
---------------------------------------------------------------------

Re: Ada is 'better' than C because...

[Sandy McPherson]

Thanks for the info, it is very interesting. I also have no particular
axe to grind about the languages, as I am a fan of both C and Ada, I
just happen to have to use C a lot more often (and have to apply QAC and
Purify rigourously) and in the sorts of programs I deal with (spacecraft
simulations) I have seen no evidence of wildly differing error densities
(maybe because we're better at C than Ada of course!). The more info I
can get on both languages (and C++) the better.

I do however have an axe to grind with people who make statements like:

"the C family of languages are inherently dangerous, because they have
pointers" 

to paraphrase the post I was replying to, and are not prepared to or
capable of providing evidence to support the statement.

-- 
Sandy McPherson	MBCS CEng.	tel: 	+31 71 565 4288 (w)
ESTEC/WAS
P.O. Box 299
NL-2200AG Noordwijk

Re: Ada is 'better' than C because...

[Mike Stark]

Folks --

I strongly recommend this report (see URL below), because it is the
closest thing you will ever see to a controlled experiment.  

This is because the Rational (formerly Verdix) VADS product is a mix of 
C and Ada, with the same development team working in both languages 
(because enhancement/ correction assignments were handed out for product 
features, not for individual modules.  It's been a while since I've read
it, but I believe only one relatively new employee hadn't worked in both
languages.

The conclusion was that Ada modules cost less and had lower error rates.
Again, read the report and you will see that there is strong evidence
backing up this conclusion, at least for the type of product and 
marketing environment compiler vendors live in.

URL for "Comparing Development Costs of C and Ada":
http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html

Mike

Re: Ada is 'better' than C because...

[Bob Kitzberger]

Sandy McPherson (sandy@wgs.estec.esa.nl) wrote:

: To get an objective view of whether one language is better than the
: other, one has to evaluate statistics on error densities in comparable
: systems written in the protagonist languages. Most people who have done
: this come to this conclusion: the choice of programming language only
: counts if the choice is between assembler and something else; and for
: most mainstream higher languages the process of software development is
: the determining factor.

We develop systems in Ada, C, and C++.  For years, defect rates were
measured for these (comparable) systems, and C did not fare well at
all compared to Ada.  We sell development environments for these three
languages, so we have no particular axe to grind.  Check our WWW page
for the article.

--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

Re: Ada is 'better' than C because...

[Robert Dewar]

Sandy said

"Since when was pointer arithmetic "essential"? It is simply convenient."

Avoiding pointer arithmetic in C is pretty restrictive, it means not
using arrays at all (remember that in C the notation a[b] is simply
a shorthand for pointer arithmetic).

Re: Ada is 'better' than C because...

[Kevin D. Quitt]

On 8 Aug 1996 00:22:01 -0400, dewar@cs.nyu.edu (Robert Dewar) wrote:

>Sandy said
>
>"Since when was pointer arithmetic "essential"? It is simply convenient."
>
>Avoiding pointer arithmetic in C is pretty restrictive, it means not
>using arrays at all (remember that in C the notation a[b] is simply
>a shorthand for pointer arithmetic).

That's a meaningful argument.  Based on this, all lanaguages have pointer
arithmetic, and it ain't so.

-- 
#include <standard_disclaimer.h>
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Theodore E. Dennison]

Tim Behrendsen wrote:
> 
> This sounds to me like the "Macintosh" argument; if only the general
> public weren't so ignorant, the Macintosh would be the dominant
> platform.  Never mind the very real problems with the platform.

Nope. I never said that, and wouldn't imply it. 

I have heard that argument used (fallciously) against Ada, and that
appears to be what you are attempting to do here. The problem is that
you are trying to introduce an analogy that just does not hold.

That argument works when you are talking hardware, because folks
don't want to switch hardware when none of their old software will 
run with it, and very little software is available for it. 

This just doesn't follow with languages. My Ada software will run on
any platform I write it to, no matter how few other Ada programs run
on that platform. It simply doesn't matter what the "general public"
(whoever that is) uses. It won't hurt your sales one iota to use
Ada instead of BLISS+++ (or whatever is "fashonable" these days). In
fact, if your customers care about reliablity, it will probably
HELP sales (then again, its 1:30 PM and I'm still sober, so obviously
I know NOTHING about Sales :-) ).

> Based on your post, Ada is only appropriate for mission critical
> applications, and not for other applications? Again, the question,

I don't believe I ever claimed such a restriction on Ada's usefullnes. 
In fact, I have used Ada with good effect for database and GUI 
applications. It is true that the more you care about reliablity, the
more you appreciate Ada. Such concerns are rightfully the most acute in
the domains I mentioned, but I should hope they are not absent elswhere.

> and I ask this respectfully, "If it's so good, why isn't it used more
> universally than it is?"  And, if C is so bad (in many people's opinion,
> not mine), why is it used almost universally, despite its acknowledged,
> real problems?

And, I ask this equally respectfully, "Why do I care?" In fact, I HOPE 
our compeditors use C. It gives our products quite a "head start", 
where quality (and often cost) are concerned.


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Ada is 'better' than C because...

[William Clodius]

In article <320a638d.534305610@netline-fddi.jpl.nasa.gov>
kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes: 

   On 8 Aug 1996 00:22:01 -0400, dewar@cs.nyu.edu (Robert Dewar) wrote:

   >Sandy said
   >
   >"Since when was pointer arithmetic "essential"? It is simply convenient."
   >
   >Avoiding pointer arithmetic in C is pretty restrictive, it means not
   >using arrays at all (remember that in C the notation a[b] is simply
   >a shorthand for pointer arithmetic).

   That's a meaningful argument.  Based on this, all lanaguages have pointer
   arithmetic, and it ain't so.

Not quite. First when passed as an argument to a user defined function
a C array looses a lot of its distinction from a pointer, a problem
that many other languages do not have. Second, while (almost?) all
languages that have arrays have indexing, a number of languages, have
additional capabilities that C arrays lack, the ability to specify
array shape in arguments (Fortran I), and various forms of whole array
operations, APL, PL/I, Algol 68, and Fortran 90.
-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545

Re: Ada is 'better' than C because...

[Kevin D. Quitt]

On 08 Aug 1996 16:46:39 -0600, clodius@hotspec.lanl.gov (William Clodius)
wrote:
>   >Avoiding pointer arithmetic in C is pretty restrictive, it means not
>   >using arrays at all (remember that in C the notation a[b] is simply
>   >a shorthand for pointer arithmetic).
>
>   That's a meaningful argument.  Based on this, all lanaguages have pointer
>   arithmetic, and it ain't so.
>
>Not quite. First when passed as an argument to a user defined function
>a C array looses a lot of its distinction from a pointer, a problem
>that many other languages do not have. 

Only notationally.  All the languages have to go through similar "pointer
arithmetic" to calculate array offsets.  In fact, with C's array-of-pointers-
as-a-two-dimensional-array, it does *less* pointer arithmetic.


>Second, while (almost?) all
>languages that have arrays have indexing, a number of languages, have
>additional capabilities that C arrays lack,

Without a doubt.  But this has nothing to do with eliminating arrays (only) in
C if pointer arithmetic is not allowed.

-- 
#include <standard_disclaimer.h>
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: Ada is 'better' than C because...

[Robert Dewar]

Kevin said

"   On 8 Aug 1996 00:22:01 -0400, dewar@cs.nyu.edu (Robert Dewar) wrote:

   >Sandy said
   >
   >"Since when was pointer arithmetic "essential"? It is simply convenient."
   >
   >Avoiding pointer arithmetic in C is pretty restrictive, it means not
   >using arrays at all (remember that in C the notation a[b] is simply
   >a shorthand for pointer arithmetic).

   That's a meaningful argument.  Based on this, all lanaguages have pointer
   arithmetic, and it ain't so.

No, that's quite wrong. Semantically in C, a[b] is just syntactic sugar
for *(a+b), and to emphasize this, it is always fine in C to replace
a[b] by b[a] (where a is the "array" and b is the "subscript"). In almost
all other Algol style languages, and in Fortran, array subscripting is a
first class operation in the language. Quite a big difference!

So the claim that all languages have pointer arithmetic semantics and use
them when the index arrays is quite wrong (for example it would be 
perfectly fine in Ada to use hash tables to represent arrays).

Re: Ada is 'better' than C because...

[OBryan Anthony H]

William Clodius (clodius@hotspec.lanl.gov) wrote:

: Not quite. First when passed as an argument to a user defined function
: a C array looses a lot of its distinction from a pointer, a problem
: that many other languages do not have. Second, while (almost?) all

  I have a hard time seeing this as a problem.  It's one of the fantastic 
advantages of the C language.  An array of any given type can be passed 
to a user function and treated as an array of any other integral type, 
converted, processed, etc. in any manner the programmer desires.

: additional capabilities that C arrays lack, the ability to specify
: array shape in arguments (Fortran I), and various forms of whole array
: operations, APL, PL/I, Algol 68, and Fortran 90.

What do you mean by array shape?  C is fully capable of performing whole 
array operations.  The capability is not embedded in the language, as C 
is designed to provide only the bare necessicities for program 
development with all else being provided in function extensions, but the 
language itself allows for anything a machine is capable of doing.

Re: Ada is 'better' than C because...

[Lawrence Kirby]

In article <4un7j3$m9g@ursa.smsu.edu>
           aho450s@nic.smsu.edu "OBryan Anthony H" writes:

>William Clodius (clodius@hotspec.lanl.gov) wrote:
>
>: Not quite. First when passed as an argument to a user defined function
>: a C array looses a lot of its distinction from a pointer, a problem
>: that many other languages do not have. Second, while (almost?) all
>
>  I have a hard time seeing this as a problem.  It's one of the fantastic 
>advantages of the C language.  An array of any given type can be passed 
>to a user function and treated as an array of any other integral type, 
>converted, processed, etc. in any manner the programmer desires.

However the results of doing so are not predictable from the language
so it is rarely if ever a useful thing to do (viewing objects specifically
as an array of char, or better still unsigned char is sometimes useful).

>: additional capabilities that C arrays lack, the ability to specify
>: array shape in arguments (Fortran I), and various forms of whole array
>: operations, APL, PL/I, Algol 68, and Fortran 90.
>
>What do you mean by array shape?  C is fully capable of performing whole 
>array operations.  The capability is not embedded in the language, as C 
>is designed to provide only the bare necessicities for program 
>development with all else being provided in function extensions, but the 
>language itself allows for anything a machine is capable of doing.

As are most other languages. However some operations are much easier
to express in some languages than others. If you want to perform a
whole array operation then that will clearly be very easy in a language
that supports appropriate whole array operations directly.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Ada is 'better' than C because...

[Bob Kurtz]

In article <4un7j3$m9g@ursa.smsu.edu>, aho450s@nic.smsu.edu (OBryan
Anthony H) wrote:

> William Clodius (clodius@hotspec.lanl.gov) wrote:
> 
> : Not quite. First when passed as an argument to a user defined function
> : a C array looses a lot of its distinction from a pointer, a problem
> : that many other languages do not have. Second, while (almost?) all
> 
>   I have a hard time seeing this as a problem.  It's one of the fantastic 
> advantages of the C language.  An array of any given type can be passed 
> to a user function and treated as an array of any other integral type, 
> converted, processed, etc. in any manner the programmer desires.

This is one of the best features of C.  This is one of the worst features
of C.  You are free to handle that passed address in any way you choose,
without substantial limitation by the language, and regardless of whether
it is sensible or whether you really meant to do it that way.  What seems
powerful when developing small programs becomes deadly when developing
large systems with many programmers.

> : additional capabilities that C arrays lack, the ability to specify
> : array shape in arguments (Fortran I), and various forms of whole array
> : operations, APL, PL/I, Algol 68, and Fortran 90.
> 
> What do you mean by array shape?  C is fully capable of performing whole 
> array operations.  The capability is not embedded in the language, as C 
> is designed to provide only the bare necessicities for program 
> development with all else being provided in function extensions, but the 
> language itself allows for anything a machine is capable of doing.

Using this argument to suggest that C provides whole-array operations is
like saying C provides for computer vision, because the machine is capable
and somebody once wrote a program ("function extensions") that did this.

In fact, there is a big difference between language-supported operations
and those "extensions" that you make by yourself.  For one, language
operations are (we sincerely hope) extremely robust and unlikely to fail. 
It takes serious measures (like good design, thorough unit and integration
testing, and preferably a history of use) to be able to make that
contention about a user-written library module.

I presume that "array shape" is the ability of a module to determine the
dimensions of an array passed as an argument.  Ada supports this (to my
great delight when I first learned about it), C does not.  That's not to
say you can't pass dimensions to the module as well, or bundle the
dimensions and the pointer to the array into a passed structure (yuck),
but it is not inherently supported by the language, and thus invites
nonstandard (even within the same project) ways of dealing with the
problem.  This, in turn, invites errors, particularly subtle ones.

So is Ada "better" than C?  Depends.  Is it "safer" than C?  Sure thing.

-Bob

-- 
Bob Kurtz (kurtz@mustang.nrl.navy.mil)
Hughes STX Corp., US Naval Research Lab, Washington DC

Re: Ada is 'better' than C because...

[Tom Watson]

In article <4un7j3$m9g@ursa.smsu.edu>, aho450s@nic.smsu.edu (OBryan
Anthony H) wrote:

> William Clodius (clodius@hotspec.lanl.gov) wrote:
> 
> : Not quite. First when passed as an argument to a user defined function
> : a C array looses a lot of its distinction from a pointer, a problem
> : that many other languages do not have. Second, while (almost?) all
> 
>   I have a hard time seeing this as a problem.  It's one of the fantastic 
> advantages of the C language.  An array of any given type can be passed 
> to a user function and treated as an array of any other integral type, 
> converted, processed, etc. in any manner the programmer desires.
> 
> : additional capabilities that C arrays lack, the ability to specify
> : array shape in arguments (Fortran I), and various forms of whole array

Please review your history, original Fortran didn't have subroutines!!

> : operations, APL, PL/I, Algol 68, and Fortran 90.
> 
> What do you mean by array shape?  C is fully capable of performing whole 
> array operations.  The capability is not embedded in the language, as C 
> is designed to provide only the bare necessicities for program 
> development with all else being provided in function extensions, but the 
> language itself allows for anything a machine is capable of doing.

What he would like to do (and this is not presently supported at all, and
is invalid syntax) is:

void routine (int n1, int n2, double a[n1][n2])
{
...
}

Or some such wonderful syntax.  It makes writing complex math things much
easier.  If you are living cleanly, and the compiler is verbose enough, it
might even check array bounds as well.  That is a "quality of
implementation" issue though.

-- 
Tom Watson
tsw@3do.com         (Home: tsw@johana.com)

Re: Ada is 'better' than C because...

[Robert Dewar]

Obryan Anthony (is this the right order?) says

"  I have a hard time seeing this as a problem.  It's one of the fantastic
advantages of the C language.  An array of any given type can be passed
to a user function and treated as an array of any other integral type,
converted, processed, etc. in any manner the programmer desires."

Nope, C, the language does not permit this, or at least says that the
semantics are implementation defined. So your C compiler may or may
not do something interesting, but you are writing highly non-portable
code if you do this. It is possible to write portable code in C, but
you have to first get rid of attitudes like this!

Re: C is 'better' than Ada because...

[system]

 "Tim Behrendsen" <tim@airshields.com> writes:
>Theodore E. Dennison <dennison@escmail.orl.mmc.com> wrote in article
><31F613F3.2781E494@escmail.orl.mmc.com>...
>> Tim Behrendsen wrote:

>> You have a good point. Unfortunately, your premise is wrong. Ada is in 
>> extensive use outside of the Government. In fact it is the language of 
>> choice wherever a software failure is liable to cause loss of life or a 
>> very large lawsuit. 
>
>This sounds to me like the "Macintosh" argument; if only the general
>public weren't so ignorant, the Macintosh would be the dominant
>platform.  

No actually it sounds more like the OS/2 argument.

>Never mind the very real problems with the platform.

What are the very real problems with Ada?

>> Mine is for languages that are the least error prone, and the easiest 
>> to track down bugs in. That way, I get to spend my evenings at home
>> with my family.

>Based on your post, Ada is only appropriate for mission critical
>applications, and not for other applications? 

This is scary, don't you WANT a language that allows you to ship
(as) bug-free (as possible) code?

Most software houses don't produce mission critical software so they
program with what they are comfortable with and never get exposed
to Ada ("Ugh, why would you want to learn that?").

>Again, the question,
>and I ask this respectfully, "If it's so good, why isn't it used more
>universally than it is?"  

Why don't more people use VMS or OS/2 or ... 

[<grin> I hope this doesn't start another religious war]

>And, if C is so bad (in many people's opinion,
>not mine), why is it used almost universally, despite its acknowledged,
>real problems?

Why was Windows 3.1 used so much? (not a perfect analogy but...)

Why are you so prejudiced against Ada?  You know next to nothing about it
But reading your original post you have essentially already decided what 
Ada is.

Try the Lovelace tutorial at
http://lglwww.epfl.ch/Ada/Tutorials/Lovelace/lovelace.html"

It will only take a couple of hours and you might learn something.

>-- Tim Behrendsen (tim@airshields.com)

Robert

Re: C is 'better' than Ada because...

[Tim Behrendsen]

system@niuhep.physics.niu.edu wrote in article
<4tijip$rlo@corn.cso.niu.edu>...
> Why are you so prejudiced against Ada?  You know next to nothing about it
> But reading your original post you have essentially already decided what 
> Ada is.

[bringing out the fire extinguisher]
I'm not; my questions/statements were in response to the points raised
by the original author.  I know nothing about Ada; it's advocates seem
to feel that is a very good language, however.  I'm curious why it
hasn't caught on, when it has had so much time to gain a larger
following that it has.  

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[Dirk Dickmanns]

"Tim Behrendsen" <tim@airshields.com> writes:

> ...

>I am totally ignorant of Ada, except for a book I flipped through a
>long time ago.  I use C, because it has the most infrastructure along
>with it, including programming talent.  I'm in business to make money,
>not to push back the frontiers of computer science (the pioneers take
>the arrows).

>My personal preference is for small nuts-and-bolts languages, anyway.
>Ada always seemed too "kitchen sink" for my tastes.

>My question is this, and I really don't mean this snidely: If Ada is so
>good, why are the only companies that use it are the ones that deal with
>the government, which make them use it?  Ada has had plenty of time to
>develop the infrastructure that C has developed, so it can't be a "I
>don't want to be first" mentality on the part of industry.

Top five why not Ada:

5 Ada always seemed too "kitchen sink" for my tastes.
4 I'm in business to make money.
3 My personal preference is for small nuts-and-bolts languages, anyway.
2 I use C.
1 I am totally ignorant of Ada.

You answered your question before stating it ;-)

Dirk

--
Dirk Dickmanns -- REALIS -- real-time dynamic computer vision
Sun OS 4.1.3; PC Linux; Ada, OCCAM, C, Eiffel, PROLOG, C++

Re: C is 'better' than Ada because...

[JamesS1889]

In article <01bb78b1$28455ec0$87ee6fce@timpent.airshields.com>, "Tim
Behrendsen" <tim@airshields.com> writes:

>I am totally ignorant of Ada, except for a book I flipped through a
>long time ago.  I use C, because it has the most infrastructure along
>with it, including programming talent.  I'm in business to make money,
>not to push back the frontiers of computer science (the pioneers take
>the arrows).

Yeah, yeah, I know what you mean.  Nevertheless, this is an extremely
shallow attitude.  You are almost totally ignorant of Ada83, and totally
ignorant of Ada95, yet you are dismissing the language based on a symptom.
 That C is more plentiful (assuming yo are even right) is at best a
prediction that C is better than Ada.  It is by no means an accurate
measurement.  At the same time, if Ada can cut your maintenance time and
increase your productivity for new applications, then the stand you have
taken may just be hurting your "bottom line".

>My personal preference is for small nuts-and-bolts languages, anyway.
>Ada always seemed too "kitchen sink" for my tastes.

Whatever floats your boat.

>My question is this, and I really don't mean this snidely: If Ada is so
>good, why are the only companies that use it are the ones that deal with
>the government, which make them use it?  Ada has had plenty of time to
>develop the infrastructure that C has developed, so it can't be a "I
>don't want to be first" mentality on the part of industry.

Or it could be due to all those people who are "totally ignorant of Ada",
except for scanning some book when Ada was in its infancy, and
nevertheless concludng that Ada is too much "kitchen sink" for their
tastes.

James Squire                                      
mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com
Opinions expressed here are my own and NOT my company's
"Only one Earth Captain has ever survived battle with a Minbari fleet.  He
is behind me.
You are in front of me.  If you value your lives, be somewhere else!"
           -- Delenn, "Severed Dreams"

Re: C is 'better' than Ada because...

[Alan Brain]

"Tim Behrendsen" <tim@airshields.com> wrote:

>
>I am totally ignorant of Ada, except for a book I flipped through a
>long time ago.  I use C, because it has the most infrastructure along
>with it, including programming talent.  I'm in business to make money,
>not to push back the frontiers of computer science (the pioneers take
>the arrows).
>
>My personal preference is for small nuts-and-bolts languages, anyway.
>Ada always seemed too "kitchen sink" for my tastes.
>
>My question is this, and I really don't mean this snidely: If Ada is so
>good, why are the only companies that use it are the ones that deal with
>the government, which make them use it?  Ada has had plenty of time to
>develop the infrastructure that C has developed, so it can't be a "I
>don't want to be first" mentality on the part of industry.

We seem to have gone full circle. As the originator of the thread, I published a 
slightly-tongue-in-cheek "C is 'better' than Ada because..." article - which has 
since been consigned to the bit bucket - showing how it was strictly for 
non-technical but very psychologically significant reasons. Like you can write the 
most apalling guff in C, and the compiler will happily swallow it, never 
tattle-taling about your errors, whereas an Ada compiler will often snidely inform 
you what an idiot you are for adding apples to oranges (unless both are subtypes of 
base type fruit) and so on.

I think the original article is worth re-publishing (Anybody out there have it??), 
because this question is a darned good one IMHO.

Re: C is 'better' than Ada because...

[Theodore E. Dennison]

Robert Dewar wrote:
> 
> to languages you don't know (althought that certainly is common -- hands
> up now all those who are sure they don't like COBOL without knowing
> a thing about it :-)




   
           ^
        ^ | | ^ 
       | || || | ^
       | || || || |
   ^   | || || || |
   \ \ |          |
    \  V          |
     \            |
      \           /
       \         |
        |        |
        |        |



I have one hard rule: I never use a computer language older than I am.
-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

>Yes, but you don't know Ada (not even how to spell the name of the language!)
>as has been clear from your previous posts. You probably also don't like
>COBOL and know nothing about it.

I've studied both of them well enough to find ADA annoying (which is why I
make it all caps) and COBOL outright disgusting.  Do *you* know what COBOL's
equivalent of BASIC's "ON x GOTO..." is?

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Theodore E. Dennison]

Kevin D. Quitt wrote:
> 
> >Yes, but you don't know Ada (not even how to spell the name of the language!)
> >as has been clear from your previous posts. You probably also don't like
> >COBOL and know nothing about it.
> 
> I've studied both of them well enough to find ADA annoying (which is why I
> make it all caps) and COBOL outright disgusting.  Do *you* know what COBOL's
> equivalent of BASIC's "ON x GOTO..." is?

EVERY language is annoying when you are first learning it, or when you are 
very much used to using a different language. C++ folks have the same problem
with Java. COBOL folks have the same problem with Fortran. Don't let that 
initial annoyance prevent you from broadening your horizons. Once you start
thinking in Ada terms, I bet you'll even find all sorts of things about C that 
annoy you.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On Wed, 24 Jul 1996 08:25:18 -0400, "Theodore E. Dennison"
<dennison@escmail.orl.mmc.com> wrote:
>Don't let that 
>initial annoyance prevent you from broadening your horizons.

I started working with computers 38 years ago.  The first ones were analog,
then mechanical-digital, and finally electronic-digital.  Not counting what
you do to the first two of those as programming languages, I have been
proficient in over 50 assemblers and 30 high-level languages.  My horizons are
sufficiently wide to evaluate other languages. 


> Once you start thinking in Ada terms, 

You shouldn't have to think in terms of the language.  If you do, it's getting
in your way and you should dump it.


>I bet you'll even find all sorts of things about C that annoy you.

I don't need Ada to find things I don't like about C; I can guarantee you I
know more of its problems than you do.  What I found from looking at Ada is
that it has more and bigger problems, and is generally a less convenient tool.
That's what I mean by getting in my way.

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Alan Brain]

kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) wrote:

>I started working with computers 38 years ago.  The first ones were analog,
>then mechanical-digital, and finally electronic-digital.  Not counting what
>you do to the first two of those as programming languages, I have been
>proficient in over 50 assemblers and 30 high-level languages.  My horizons are
>sufficiently wide to evaluate other languages. 

Excellent! Just the type of bloke that my argument will appeal to. I might add I 
wrote my first Fortran II in 1968... so am a relative newbie. (My Dad taught me - 
he'd been working using the Ferranti Pegasus, Ace and Deuce, while my Uncle was in 
the game since COLOSSUS.. but I digress...)

>> Once you start thinking in Ada terms, 
>
>You shouldn't have to think in terms of the language.  If you do, it's getting
>in your way and you should dump it.

Remember when you had to think in 11010001 and 11110011 ? Then came along such 
snappy things as ADD A1,A2? Later on, JMP 07715226 could be replaced by JMP IOHANDLE 
? Later still, you could use loops, then case statements, and so on.

You can still do everything you want by flipping the switches on the front panel. 
But a high-order-language that encourages reliability and maintainability will have 
features so you can get the compiler to check you haven't stuffed up in one of a 
million ways. It should also allow the run-time executive to easily check your code 
during execution, to make sure you haven't screwed up in a million others.

IMHO the language DOES affect your thinking, so you're not troubled by wondering 
exactly what bytes contain a particular variable; you should only be concerned with 
what things you really have to know about it. And if some idjit down the corridor 
changes the representation of the data-type from taking 11 bits instead of 13, so 
what's it to you? But what you do spend your time thinking about is exception 
handling, error-correction, designing so as to minimise impact on other development 
teams, designing so other teams can change internal structures without you having to 
change anything you've written, etc.

Forex, a project I was on switched from having 5 intercommunicating processes 
running in sequence to running them in parallel a week before first delivery. I'd 
designed them so either way would work.
 
>I don't need Ada to find things I don't like about C; I can guarantee you I
>know more of its problems than you do.  What I found from looking at Ada is
>that it has more and bigger problems, and is generally a less convenient tool.
>That's what I mean by getting in my way.

Question: How many kLOCs have you written in Ada? How many in C?

Until you've written at least 2K in Ada, 2K in C, on a real live project, IMHO any 
comparison is iffy. The learning curve for Ada IF SELF TAUGHT can be very rocky. 
With a good teacher - eg the on-line Lovelace Tutorial - heaps easier. I encourage 
you to have a look at it.

My own total is about 17 KLOCs in C (K&R mostly), 50+ in Ada-83, but none in C++ or 
Ada-95, so I don't comment on them. Yes, a few K in each on my PC, but none on a 
genuine project.

Re: C is 'better' than Ada because...

[Steve Howard]

Kevin D. Quitt wrote:

> I don't need Ada to find things I don't like about C; I can guarantee you I
> know more of its problems than you do.  What I found from looking at Ada is
> that it has more and bigger problems, and is generally a less convenient tool.
> That's what I mean by getting in my way.
> 

What are the problems that you feel "more and bigger" in Ada than C? I certainly could 
believe the argument that Ada might be less convenient for a quick hack than a language 
like C, but I have found in my own code, as well as in reviews of other people's code, that 
there are whole classes of errors that just don't happen under Ada.


-- 
E. Steve Howard                | Lockheed Martin
                               | Ocean, Radar, & Sensor Systems        
mailto:howard@mtm.syr.lmco.com | Syracuse, NY

Re: C is 'better' than Ada because...

[Bob Kitzberger]

Kevin D. Quitt (kdq@emoryi.jpl.nasa.gov) wrote:

: You shouldn't have to think in terms of the language.  If you do, it's getting
: in your way and you should dump it.

'member that the next time you catch yourself thinking in English :-)


--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

Re: C is 'better' than Ada because...

[Mike Roske]

Theodore E. Dennison wrote:
> 
> Kevin D. Quitt wrote:

> Once you start
> thinking in Ada terms, I bet you'll even find all sorts of things about C that
> annoy you.

I believe that a more accurate statement might be: "Once you start
thinking in terms of software structure, flexibility, and future
maintenance, I bet you'll find something about ANY language that
will annoy you."

The good news is that Ada was designed with these things in mind.
More good news is that C++ was also designed with these things in mind.
Still more good news is that these things can be achieved in ANY
language.

--> Mike



-- 
*-------------------------------------------------------*
* Michael Roske
* Sanders, A Lockheed Martin Company
* mroske@mailgw.sanders.lockheed.com
* (603) 885-9240
*-------------------------------------------------------*
* "I'd rather be flying RC..."                     
*-------------------------------------------------------*

Re: C is 'better' than Ada because...

[Fergus Henderson]

Kevin D. Quitt wrote:
> 
> >Yes, but you don't know Ada (not even how to spell the name of the language!)
> >as has been clear from your previous posts. You probably also don't like
> >COBOL and know nothing about it.
> 
> I've studied both of them well enough to find ADA annoying (which is why I
> make it all caps) and COBOL outright disgusting.  Do *you* know what COBOL's
> equivalent of BASIC's "ON x GOTO..." is?

Oh, you mean

	evaluate x
	   when 1
	      ...
	   when 2
	      ...
	   ...
	end-evaluate

?
I don't find anything particularly disgusting about COBOL's `evaluate'
statement.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On 25 Jul 1996 05:59:17 GMT, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote:
>>Do *you* know what COBOL's
>> equivalent of BASIC's "ON x GOTO..." is?
>
>Oh, you mean
>
>	evaluate x

No, that's like C's switch statement.  COBOL uses self-modifying code for
computed gotos.

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[kennedy1]

In <31f7db04.80562082@netline-fddi.jpl.nasa.gov>, kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes:
>No, that's like C's switch statement.  COBOL uses self-modifying code for
>computed gotos.

No it doesn't.  COBOL's <GO TO paragraph-1, paragraph-2... DEPENDING ON 
integer> statement works just like FORTRAN's computed GO TO statement.  (A 
given compiler might produce self-modifying object code to implement it; but 
that's neither here nor there; I have known hardware where self-modifying code
was the only way to return from a subroutine.)

You're thinking of the <ALTER paragraph-consisting-of-one-go-to-statement TO
PROCEED TO new-target> statement, which is the COBOL equivalent of a FORTRAN
ASSIGNed GO TO.  It is worse than the FORTRAN version, because there is no
clear evidence in the GO TO that it is ever altered, aside from the fact that
a paragraph consisting of only a GO TO is rare otherwise.  (Also, the
statement may read <GO TO.>, in which case it is clear to the reader that an
ALTER must exist.)

But even that isn't as horrid as the COBOL <PERFORM paragraph-1 THRU
paragraph-2> statement, which does a goto to paragraph-1 after inserting an
invisible, self-erasing goto at the end of paragraph-2.  Many's the time I've
hit code that took a "wild branch" when the program started a PERFORM THRU,
did a GO TO out of it (perhaps aborting a bad transaction), and later, while
processing a wholly separate transaction, happened to drop through to
paragraph-2, where the uncancelled invisible goto was still lurking.  It's
contemplating stuff like this that makes me recall how COBOL almost didn't get
an IF statement "because 'if' isn't a verb," or how no-one ever got around to
defining the results of the COBOL <COMPUTE variable = arithmetic-expression>
statement.

Re: C is 'better' than Ada because...

[Fergus Henderson]

kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes:

>On 25 Jul 1996 05:59:17 GMT, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote:
>>>Do *you* know what COBOL's
>>> equivalent of BASIC's "ON x GOTO..." is?
>>
>>Oh, you mean
>>
>>	evaluate x
>
>No, that's like C's switch statement.

Well, you're right that COBOL's evaluate statement isn't the exact
equivalent of BASIC's "ON x GOTO..." statement, even though it is what
a modern COBOL programmer would probably use for the same sort of
thing.  But it's not equivalent to C's switch statement either -- C's
switch statement is much more low-level and primitive in comparison,
really.  (For example, you can't switch on strings.)

The exact COBOL equivalent of BASIC's "ON x GOTO ..." is the

	goto ... depending on x

statement, which has pretty much identical semantics.

>COBOL uses self-modifying code for computed gotos.

I suppose you'd be referring to a feature of some ancient
version of COBOL that was deprecated years before C was ever
standardized?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On 18 Jul 96 07:12:10 GMT, nasser@apldbio.com (Nasser Abbasi) wrote:
>But on a side point, I dont think measuring productivity of 
>a programmer by lines of code makes any sense.

It certainly makes much less sense now than it used to, when good libraries
etc., weren't readily available.


>But for someone today to write code in assembler, unless there
>is a very good reason to, really do not make sense.

Agreed.  Bad assembler is worse than bad anything else, except microcode.  It
should be used only when necessary due to real-time constraints or hardware
idiosyncracies.


>So I assume you turn off the type checking feature of your compiler when
>you compile?  :)

No, it catches typos that would otherwise take another iteration to find.  I
also have it set to the highest levels, to catch those occasions when I
haven't been careful about casting variables.


>Well, there might be truth to this, but this is like throwing the baby
>with its bath water . 

People shouldn't not use those features just because there can be a problem.
But it *can* be a problem, especially when the programmer depends on the
compiler to catch everything, and then goes to a different compiler that
doesn't bother (and the programmer isn't equipped to find the problem).  I
don't mean to say that this is a common problem/


>Just becuase some programmers will not bother
>checking things too carefully befor submitting the code the compiler becuase
>they say , lets let the compiler tells use what's wrong, this do
>not mean that the whole idea of compilers that do strong checking are
>bad idea. 

I agree, and as I said, I usually invoke the strongest warning levels
available.


>This is also like saying that cars with strong breaks are bad
>idea, becuase some people will then speed up too much knowing that if they
>have to stop suddenly, the breaks will always stop the car in time, and
>they become sloopy drivers instead of slow carfull driver, so becuase of
>this we then should not build cars with strong breaks.

Actually, people with ABS brakes on their cars have been sued by people who
have rear-ended them.  After all, the argument goes, if the car in front
didn't have ABS brakes, it wouldn't have been hit.


>The more strict the compiler, the better it is. I want the compiler to
>be very picky. 

So do I.


>I like picky compilers and picky langauges, 

I agree with the former but not the latter.


-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Robert Dewar]

   >Because the number of lines of code per day per programmer is
   >fairly constant regardless of language.  Using high-level languages
   >allows programmer to  produce more software in a given period.



This often-quoted statistic is misleading, it evaluates production time,
but does not take into account life-cycle maintenance costs. If you
take these costs into account, productivity, even measured in lines/day
is much lower for assembly language programs.

Also if you take into account reusability, which also affecets long term
productivity, assembler looks even worse.

Re: C is 'better' than Ada because...

[Richard Riehle]

On 18 Jul 1996, Nasser Abbasi wrote:

The following absurdity is nested too deeply for me to determine
who actually authored it, but it cannot go without comment.


>    >What I said is that it's as easy to write high-quality software in
>    >assembler  as it is in any language.  It's not the language that's
>    >the problem.  It's the  programmer.  A high-quality programmer will
>    >turn out high-quality code regardless of the language, and a poor
>    >programmer will turn out poor quality code no matter how hard the
>    >language tries to prevent him.

  Putting aside any specific language for a moment, did the author of
  this little gem really believe what he wrote when he/she said"

    "... it's as easy to write high quality software in assembler
     as it is in any language"  ????

  While the "high quality" programmer is coding the two hundred lines
  of preparatory housekeeping code to implement some simple routine
  to open a file, the COBOL/Ada/C++ programmer is simply coding an
  "open" statement.  What's that, you say? You will use a "macro."
  Sorry, you are restricted to pure assembler. No constructs that
  are reminiscent of high-order languages are allowed.

  Even Forth programmers know the virtue of "abstraction."

  Language does make a difference.  Some languages are inherently
  dangerous. Some more than others.  A language such as COBOL 68/74
  which depends on global data is well-known for its difficulty in
  long-term maintenance.  That is why we saw COBOL 85 make it
  possible to fix that problem.  C, a universal assembler is known
  to be dangerous because of its dependence on pointer gymnastics.
  C++ brings some relief (though not enough). Eiffel, with all of its
  excellence, brings automatic garbage collection (as does Java) and
  limits its viability for certain classes of hard, real-time systems
  (HRTS) applications.

  Language does make a difference. And selecting the appropriate
  language can also make an important difference.

  Ada is weak in the availability of off-the-shelf development tools.
  I know some of you don't believe this, but take a look at your recent
  issue of Programmer's Paradise or other catalog of software development
  tools.  C++ is strong in the availability of tools.  If you want to
  do Windows 95 or NT programming today, your main option is C++.

  Language does make a difference.  If I have a serious effort in
  mathematics to complete, do you think I will turn down an opportunity
  to use Mathematica?  Well, I could always put a paper bag over its
  head and pretend it is Ada.

  Of course language makes a difference.

  Richard Riehle

Re: C is 'better' than Ada because...

[Ian Ward]

In article 342948604@netline-fddi.jpl.nasa.gov, kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes:
>On Fri, 5 Jul 1996 09:29:56 +0100, Peter Amey <pna@erlang.praxis.co.uk> wrote:
>>"The superior pilot uses his superior judgement to avoid situations that 
>>would require his superior skill"
>>
>>I use Ada precisely because it avoids the need constantly to demonstrate
>>my superior skill :-)
>
>I do the same in C.  The problem is that Ada won't *let* you use your superior
>skill, i.e., nothing is gained by it.  For someone who knows what they're
>doing, it's just as easy to write good, clean, safe code in C (or assembly, or
>*any* language) as it is in Ada.
>

It is possible, but not as easy; Each language, assuming it actually
was designed, was designed for a certain reason, it therefore stands
to reason that some languages must be, on average, empirically easier
to use than others.

I'm not the only person to think so, either. If you don't believe
me, read Byte July 1996, page 163. (Not that I totally agree with
what Mr. Pournelle says, but his views are derived from the fact
that he finds Visual Basic easier to produce simple apps on his
machine, than he does with some other language.) 

For further information, in fact the only study I know of, NOT
based on heresay, check out
http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html

I don't deny the principle of what you are saying, that 
geniuses get less help from helpful languages, than ordinary
people, but they still get some help, and 50% of programmers
are below average.


>-- 
>#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
> _
>Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
>Per the FCA, this email address may not be added to any commercial mail list

---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be
50% of programmers REALLY are below average.

Re: C is 'better' than Ada because...

[Hamilton Link]

Going back to the bit about Ada vs. assembly -- Kevin says (to paraphrase,
pardon me if it's not completely accurate) that

1) programming well is just as easy in assembly as Ada, and
2) the lines-of-code produced per day per programmer is a constant

Now, I realize that he's talking about programming in C with small amounts
of assembly to optimize the really small time-critical sections, but even
so I think I have reason to be just a tiny bit dubious.  When I program, I
sit at my computer and punch in Ada for days at a time (pausing briefly to
doze off).  Before I program, however, I do research on what algorithms
and structures would best suit my purpose.  A good algorithm written in
whatever language you want with a good compiler will be almost as fast as
any other implementation of the same algorithm, with very few exceptions
and a very small spread in run-times.  If you don't believe me, read "The
Zen of Assembly Programming".  The author makes the same point, and this
is coming from a really awesome assembly coder.

But for this very slight percent speedup, what has been sacrificed?  Let's
make a list:

Readability -- shot to hell and flushed down the toilet, for the vast
majority of cases

Portability -- unless you're fortunate enough to be porting between
virtually identical machines, you're going to have to totally rewrite your
code (Or -- shudder -- someone else is)

Modifiability -- want to change a BST into a balanced Red/Black BST? 
you're once again going to have to start over, rather than modify your
data structure and add a little to your code

I personally don't think that the sacrifices are worth the extra 10%
speedup, unless you're really hurting for it.

The other thing that really got me was that Kevin prefers spectacular
failures to mild ones.  I prefer OS/2 to DOS because when something goes
wrong I can kill the process rather than reboot my machine.  Why?  Because
OS/2 is a more advanced design.  Likewise, I like Ada's exception handling
protocol (which even in the worst case allows me to exit gracefully) over
the random core dumps that gcc seems to be so fond of.

just my 2 cents,
hamilton

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On Thu, 18 Jul 1996 08:52:35 -0600, helink@sandia.gov (Hamilton Link) wrote:
>1) programming well is just as easy in assembly as Ada, and

My point is that it must be the programmer who writes well; a language cannot
force you to write good code.  It can certainly help.

A poorly chosen algorithm is not an excuse for using assembler to help regain
the time lost due to the original poor design.  For those occasions where
response time has to be measured in micro-seconds or less, HLLs rarely
suffice.  When they do, use the HLL.


>But for this very slight percent speedup, what has been sacrificed?  Let's
>make a list:...Readability...Portability...Modifiability

Which is why it shouldn't be used unless it's the only thing that will make
the project work.  For commercial applications, and even most OS work, it
isn't necessary and shouldn't be used.  For embedded applications with special
hardware and special requirements, it's likely always to be necessary.


>I prefer OS/2 to DOS because when something goes
>wrong I can kill the process rather than reboot my machine. 

Under any circumstances you want to be able to determine the problem.  I was
speaking more towards writing through a null pointer under UNIX versus under
MSDOS.  In the former, you get a core dump (or trapped back to your debugger)
such that you can always determine where the write takes place.  Under MS-DOS,
you get a cryptic message when you exit the program, with no way to tell where
the offense occurred.  This latter tends to make for programs that work by
accident, and not by design.


I don't think we really disagree (much, anyway).  I do not think people should
be programming in assembler unless that's what it takes to make things work at
all; doing embedded code, the credo is "whatever's necessary" (accent on the
necessity).

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Stephen M O'Shaughnessy]

In article <31e02c32.342948604@netline-fddi.jpl.nasa.gov>, 
kdq@emoryi.jpl.nasa.gov says...

>  For someone who knows what they're doing, it's just as easy to write good, 
clean, safe code in C (or assembly, or *any* language) as it is in Ada.
>

No it is not.  It is *possible* in any language, but not *just as easy*.  If 
that were true, then all languages would be the same.  They are not.

Re: C is 'better' than Ada because...

[Peter Seebach]

In article <DuBuJq.JM3@most.fw.hac.com>,
Stephen M O'Shaughnessy <smosha@most.fw.hac.com> wrote:
>In article <31e02c32.342948604@netline-fddi.jpl.nasa.gov>, 
>kdq@emoryi.jpl.nasa.gov says...
>>  For someone who knows what they're doing, it's just as easy to write good, 
>clean, safe code in C (or assembly, or *any* language) as it is in Ada.

>No it is not.  It is *possible* in any language, but not *just as easy*.  If 
>that were true, then all languages would be the same.  They are not.

Nonsense.  The differences between languages have primarily to do with what
tasks they're good for, and what tasks are easy to express in them, not with
cleanliness or safety.

I'm not sure I agree that it's as easy to write safe code in C as in any other
language.  But if it were, that would not make those languages the same; in
all probability, the other one would not be as convenient for system level
programming, and C would not be as convenient for high level programming.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

Re: C is 'better' than Ada because...

[Brian Rogoff]

I promised myself not to get involved in this, but hey, you only live once!

Sandy McPherson <sandy@wgs.estec.esa.nl> writes:
   John F. Bode wrote:
   > It *is* a lot harder to shoot yourself in the foot with Ada than it is
   > with C, though.

   However, when something does go wrong, your whole leg is likely to
   disappear!

Actually, you blew the joke. First of all, it was C++ that blows your leg off.
Second, the joke on Ada was that after loading the gun and pulling the 
trigger, the Ada compiler tells you your foot is of the wrong type. From 
your statement above, I can only gather from that comment that you have not 
used Ada for anything significant. 

   It depends upon which type of large system you wish to implement. Ever
   tried to write an operating system, or a configurable toolkit, which needs
   to use callbacks, in Ada? Yeuch!!! A Motif based GUI? Head for the hills!

The convention being adopted in the Ada newsgroup is to refer to Ada 95 as 
"Ada", and to refer to the previous version of the language as "Ada 83". I 
assume that you are referring to Ada 83, which did not have access to 
procedure/function. I agree that this was a shortcoming of Ada 83, and has 
been corrected in Ada (95).

   In these areas C or C++ wins every time. Whether this is a problem of Ada
   as a language is disputable, as these types of systems are traditionally
   the stamping ground of C anyway; however as a great believer in making life
   easy for myself, I would stick to C/C++ in these areas.

Suit yourself. There are many good reasons for using C, but the ones you 
mentioned no longer apply.

   The main advantage that C has over Ada is that the compilers are generally
   very reliable (because of their small size) and produce efficient machine
   code. If you have good PA standards and the correct tools (lint, QAC,
   Purify, to name but a few) you can achieve very good results with C,
   sometimes better than with Ada. 

None of those tools are necessary with Ada.

   Tasking looks like a good idea,
   but the implementations can be weak; in fact most spacecraft control
   systems I have seen implement their own tasking mechanisms, especially
   where they have to respond to hardware interrupts.

Ada 95 includes protected types, for a monitor-like synchronization mechanism.

   Ada should be better than C for most applications, but has certain
   weaknesses. Let's see what Ada 95 brings, or shouldn't we all be looking at
   Eiffel?

Which weaknesses vis-a-vis C (or C++) do you have in mind?

Eiffel is superb, but I think Ada 95 provides better system programming 
capabilities, and a hierarchical module system. Also, there is a FREE 
Ada 95 compiler which runs on lots of architectures.

-- Brian

Re: C is 'better' than Ada because...

[James A. Squire]

Sandy McPherson wrote:

> It depends upon which type of large system you wish to implement. Ever
> tried to write an operating system, or a configurable toolkit, which needs
> to use callbacks, in Ada? Yeuch!!! A Motif based GUI? Head for the hills!

Au Contraire, especially in Ada95.  With access-to-subprogram variables
and Interfaces.C, the clear choice in my book would be Ada95 every time.

> In these areas C or C++ wins every time. Whether this is a problem of Ada
> as a language is disputable, as these types of systems are traditionally
> the stamping ground of C anyway; however as a great believer in making life
> easy for myself, I would stick to C/C++ in these areas.

As a great believer in making like easy for future maintainers, I find
this shallow reasoning.

> If on the other hand you have a bare chip and need to write a complex
> embedded system, (and you have a GOOD Ada compiler), then Ada is probably a
> better starting point, because there are so many fetures built into the
> language which you have to do manually when coding good C.

There are tons of Ada advocates in this newsgroup quite skilled at
filleting this one into little pieces.  I leave it to them.  It's not
that what you have said here is patently false, it's the hidden
implications behind it that are bogus - namely, that THAT is ALL Ada is
good for.

> The main advantage that C has over Ada is that the compilers are generally
> very reliable (because of their small size) and produce efficient machine
> code. If you have good PA standards and the correct tools (lint, QAC,
> Purify, to name but a few) you can achieve very good results with C,
> sometimes better than with Ada.

They can also make hash out of this one too.  The best I can do is to
say that your implication that C compilers are generally more reliable
than Ada compilers is unsubstantiated in any way.

> The main advantage Ada has over C is its well defined source architecture
> and easily employed data abstraction facilities and the tools which are
> built into the APSE; these have to be built into a good C program, but a
> plonker will bugger this up in Ada as well. Tasking looks like a good idea,
> but the implementations can be weak; in fact most spacecraft control
> systems I have seen implement their own tasking mechanisms, especially
> where they have to respond to hardware interrupts.

1.  Very clever.  Hypothetically propose an advantage of Ada over C and
then dismiss it by appealing to the universal weakness of human nature.
Human nature is weak, but C gives it a head start over Ada.

2.  Tasking may have improved considerably in Ada95.  Besides, what
feature of C are you comparing tasking to?
--
James Squire                             mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com/
Opinions expressed here are my own and NOT my company's
"Nice shark...pretty shark..."
        -- Londo, "The Gathering"

Re: C is 'better' than Ada because...

[William Clodius]

In article <01bb7bfc$3c5ca460$96ee6fcf@timhome2> "Tim Behrendsen"
<tim@airshields.com> writes: 

   Ken Garlington <garlingtonke@lmtas.lmco.com> wrote in article
   <31EF7E48.5ABE@lmtas.lmco.com>...
   > Sandy McPherson wrote:
   > > and produce efficient machine code.
   > 
   > Why is this an advantage of C over Ada? Ada certainly produces efficient
   > machine code, given a good compiler. In fact, there are examples of Ada
   > outperforming C with regard to efficiency.

   The one big advantage C has traditionally had over other
   languages is efficient compilation.  The reason is that 'C' is one
   of the few languages that provides concepts such as register
   variables to give hints to the compiler.

This ignores Garlington's reply. If this was important, why do
languages such as Ada, Fortran, Sisal, etc., often generate more
efficient code than C athough they lack that hint?  On heavily
pipelined processors, register scheduling is such a complex task that
the human analysis is rarely useful and that hint is almost uniformly
ignored. As to compiler speed, while C's coding brevity helps some
aspects of compilation, its typical reliance on macros and the details
of its declaration syntax result in a language that is harder to
compile than some other languages such as Oberon.

   Yes, you can wave your hand and say, "well, the compiler
   should take care of that".  But then, reality rears its head, and
   we realize that there are *no* compilers that are that smart.
   Here's an old saying that I just made up ...

   Behrendsen's Law: "All optimizers are crap."

   We will never have an optimizer that can do as good a job
   as human optimization until we get "strong AI", but that would
   take an actual science of AI to exist (let's not get started on
   *that*!).  C is one of few languages that recognizes this.

While on modern processors a human can still compete with a compiler
on small pieces of code, provided he works directly in assembler,
doing that on every portion of a significant code is too exhausting
for humans. C is no substitute for assembler in such cases. The
aspects of C that are thought of as resembling assembler, either loose
semantic information usefull for global analysis, e.g., the
distinction between pointers and arrays, or are shorthands for
constructs, e.g., i=i+1, that are easily recognized by any compiler.

   Since C is such a small language, this also makes it
   easier for the compiler/optimizer to a (relatively) good job.

Most compilers nowadays use backends that are common among several
languages, and most optimizations are performed in the language
independent backends.  The size of the language has relatively little
effect on optimization compared to the detailed semantics of the
language. Strong typing in any language helps with optimization, and
both C and Ada (indeed many other languages) have strong
typing. Unfortunately, while C is a small language, its reliance on
pointers and side effects introduces optimization problems not present
in many other languages, e.g, Ada, Fortran, Sisal, etc.
-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545

Re: C is 'better' than Ada because...

[Richard A. O'Keefe]

In article <01bb7bfc$3c5ca460$96ee6fcf@timhome2> "Tim Behrendsen"
<tim@airshields.com> writes: 

>   The one big advantage C has traditionally had over other
>   languages is efficient compilation.  The reason is that 'C' is one
>   of the few languages that provides concepts such as register
>   variables to give hints to the compiler.

I would remind readers of the figures I recently posted for a numerical
integration program on an UltraSparc:
	C:      13   seconds (SPARCompiler C SC4.0)
	Scheme:  5   seconds (Stalin 0.6, then SPARCompiler C)
Well, those figures are out of date.
	Scheme:  0.9 seconds (Stalin 0.7, then SPARCompiler C)

>   Yes, you can wave your hand and say, "well, the compiler
>   should take care of that".  But then, reality rears its head, and
>   we realize that there are *no* compilers that are that smart.
>   Here's an old saying that I just made up ...

>   Behrendsen's Law: "All optimizers are crap."

There are some truly *awesome* modern compilers.  One of the reasons that
Stalin gets the time way down is that it optimises the *whole* program,
including specialising the run-time system for this particular program.
It does some truly *amazing* things that no sane programmer would dream
of doing, or having done, would ever be willing to do a second time.
The VORTEX compiler for Cecil also does truly awesome things.  One of
the things VORTEX does and Stalin doesn't do is that it will use the
run-time profile from a previous execution of the program to guide its
optimisation this time round.  Guess what:  SPARCompiler C can do it too.
(MIPS have been doing it for years.)  Human programmers just don't do this
except on code of the utmost importance, and then they just don't live
long enough or work fast enough to keep their tuning up to date with
changes to the program.

I further note that the SPARCompiler C compiler can optimise *differently*
for several versions of the SPARC, several versions of the PowerPC, and
several versions of the 80*86.  On the SPARC, it wants to know the size of
the cache!  I haven't the slightest clue what it does with it, and what I
know from the literature of what it *could* do with that information tells
me that once again, it is taking advantage of information that the average
programmer does not have and could not use if s/he had it.  (To start with,
I didn't even know what model of SPARC I have; I had to ask the compiler
what it thought -native meant!)

One of the ways SPARCompiler C gets better performance than earlier C
compilers from Sun is that it *ignores* programmer-supplied 'register'
declarations (I think there is a command line option to honour them, but
I haven't ever bothered using it).  And Scheme, of course, has never had
such things.

>   We will never have an optimizer that can do as good a job
>   as human optimization until we get "strong AI", but that would
>   take an actual science of AI to exist (let's not get started on
>   *that*!).  C is one of few languages that recognizes this.

You just haven't a clue about the things modern compilers can do, and do do.
Loop unrolling, strip-mining, vectorising, analysing the class hierarchy so
as to replace dynamic dispatch by inlined code, branch prediction based on
profiles, AND IT ALL HAPPENS EVERY TIME I RUN THE COMPILER.  What we get
right now is better than almost every programmer there is, and we get it
far cheaper.

And you know what?  C is one of the *harder* languages to optimise!
-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: C is 'better' than Ada because...

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<4tkeuk$cu2@goanna.cs.rmit.edu.au>...
> In article <01bb7bfc$3c5ca460$96ee6fcf@timhome2> "Tim Behrendsen"
> <tim@airshields.com> writes: 
> >   Behrendsen's Law: "All optimizers are crap."
> 
> [paraphrase: Modern compilers *awesome*, global optimizations, run time
> [profiles for next compilation cycle. Humans too busy to/can't do this]

I'm not going to claim to have used every compiler, obviously, but
I base this opinion on often viewing the assembly language output when
I get a core dump or during debugging sessions.  Now, I've used a lot
of assembly language, so I usually write my C code to be easy on the
optimizer (use pointers when needed rather indexes, for example), and
I admit that sometimes optimizers are very good.  The problem is, the
compiler often doesn't have enough contextual information to know what
to do compared to the human writing the program, which bring us to ...

Global optimization: The compiler can often make decisions better
than the human can because of the large scope of global optimizations,
but again, the information needed to know when certain areas are
going to be used a lot versus other areas is not known at compile
time, which moves us to ...

Run time profiling/compiler feedback: This can certainly provide
good information back to the compiler, but it seems a little
dangerous.  I have not used this type of optimization, so my
opinion means little in this case, except for just my general
impression.  Anything other than a trivial program is going
to be very difficult to simulate real-world conditions in order
to get an optimal result.  The downside is if your test conditions
are wrong, you may end up with a "most pessimum" optimization.

It just seems to me that there is no substitute for a well
thought-out design.  Depending on the compiler to save bad design
is just a bad idea.

> >   We will never have an optimizer that can do as good a job
> >   as human optimization until we get "strong AI", but that would
> >   take an actual science of AI to exist (let's not get started on
> >   *that*!).  C is one of few languages that recognizes this.
> 
> You just haven't a clue about the things modern compilers can do, and do
do.
> Loop unrolling, strip-mining, vectorising, analysing the class hierarchy
so
> as to replace dynamic dispatch by inlined code, branch prediction based
on
> profiles, AND IT ALL HAPPENS EVERY TIME I RUN THE COMPILER.  What we get
> right now is better than almost every programmer there is, and we get it
> far cheaper.

The above are all worthwhile opimizations; I'm not claiming that
optimizers do nothing.  All I'm saying is that too often programmers
fall back on the lazy line, "Oh well, the compiler should take care
of that."  For example, if I have ...

for (i = 0; i < 10000000; ++i) 
    array[i] *= abs(values[i]);

Should I be *sure* this is going to be done efficiently, and use
pointers, or should I just let the compiler handle it? I say that
a competent programmer should use pointers out of habit, because
its just good design and practice.  And when the problem becomes
less trivial than the one above, the programmer will already be
using the proper techniques *the first time*, rather than having
to go back and fix the inevitable performance bottlenecks.

I think you are being too optimistic that optimizers produce
better code than "almost every programmer there is".  If that were
true, then projects would *never* be written in assembly language.

As it stands, we know that often times things are written in
assembly for performance reasons, such as device drivers.
The perfect example of this are computer games.  If your theory
were true, then they would all be written in high-level languages
to gain the best performance.  We know that this isn't the case,
however.  A bright human can always outdo the optimizer.

> And you know what?  C is one of the *harder* languages to optimise!

You are probably right, if you let the optimizer handle everything.
But C also gives the capability to do things such as ...

if ((array[++n] = GetValue(arg)) != 0) {
    ....

v.s. a typical non-C language ...

n = n + 1;
array[n] = GetValue(arg);
if (array[n] != 0) {
    ...
}

Now, which is easier to optimize?  For this trivial case, a
modern compiler would probably do exactly the same thing, but
what about when it starts getting non-trivial?  If I code my
expressions to take advantage of the "data flow" nature of C's
syntax, I can make it very easy for the optimizer to do a
great job.  And it's not any more work, it's just a matter of
experience and living in reality, and not pretending that the
compiler is smarter than it really is.

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[Byron B. Kauffman]

Tim Behrendsen wrote:
> 
snip...
> 
> You are probably right, if you let the optimizer handle everything.
> But C also gives the capability to do things such as ...
> 
> if ((array[++n] = GetValue(arg)) != 0) {
>     ....
> 
> v.s. a typical non-C language ...
> 
> n = n + 1;
> array[n] = GetValue(arg);
> if (array[n] != 0) {
>     ...
> }
> 
> Now, which is easier to optimize?  (more snip)
> 

Tim, I'm 180 degrees out of phase from you, experience-wise. I've
professionally done around 10klocs of Ada, and about 24 or so lines of
C, although I sucked it up and took C++ from a local junior college last
fall just so I can say that I did.

With all that in mind, I'm going to ask (in reference to the code
samples above), which is easier to read and/or maintain? The answer,
from my C-ignorant perspective, is the non-C example, but a C compiler
obviously wouldn't have a problem with it. Unfortunately, though, the
compiler is not the one that maintains or ports the code to another
platform. IMHO, this is where Ada has the edge over C - it was designed
primarily with the -ilities in mind. I don't know if it is the industry
norm, but my primary job description for years was 80% code maintenance
and rehosting, 20% new code. It is my perception that that is what was
eating DoD's lunch and why they commissioned Ada.

Why isn't it used more? If you ask two people to write a program without
specifying the language (one knows Ada better than C, the other knows C
better than Ada), their first choice will be their favorite language.
Why? Because that's what they are most comfortable with. A friend of
mine (a C guy) was trashing Ada (too slow, etc.) and I managed to turn
it around on him. He admitted, that, well, he just didn't know that much
about Ada, so it would take him longer to do something in Ada than in C.
If my professional experience track was "assembler - FORTRAN - C"
instead of "assembler - FORTRAN - Ada - C", I might feel differently.

Re: C is 'better' than Ada because...

[Ian Ward]

In article 372A@lmtas.lmco.com, "Byron B. Kauffman" <KauffmanBB@lmtas.lmco.com> () writes:
>Tim Behrendsen wrote:
>> 
>snip...
>> 
>> You are probably right, if you let the optimizer handle everything.
>> But C also gives the capability to do things such as ...
>> 
>> if ((array[++n] = GetValue(arg)) != 0) {
>>     ....
>> 
>> v.s. a typical non-C language ...
>> 
>> n = n + 1;
>> array[n] = GetValue(arg);
>> if (array[n] != 0) {
>>     ...
>> }
>> 
>> Now, which is easier to optimize?  (more snip)
>> 

Can I just ask, whether these would result in different code to 
be generated? I would have thought that any decent compiler
would generate the same code for both. (I have not written
a _modern_ compiler though, so I cannot be sure.) The only
difference between these two cases is that the second uses
more characters and is a bit easier on the eye. (Actually
both are quite easy on the eye, but these are very simple
cases. I can imagine a more complex case, say involving half
a dozen different pointers to functions returning an array
of pointers to arrays of pointers to an array of functions
returning a pointer to int, where the first example would
be much more concise than the second example. I still think
in the complex case that the resultant assembler would not
be too much different.)

Anybody au fait with current 'C' compilers to confirm this?

---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be

Re: C is 'better' than Ada because...

[Robert Dewar]

Sandy said

"   The one big advantage C has traditionally had over other
   languages is efficient compilation.  The reason is that 'C' is one
   of the few languages that provides concepts such as register
   variables to give hints to the compiler."


This is incorrect. In practice the register declarations are useless to
a modern optimizing compiler, and merely represent an unuseful attempt
to intefere with choices that the compiler can make better anyway. Most
modern C compilers, including gcc, pretty much ignore register declarations
(they cannot be completely ignored, since they introduce some (rather ugly)
semantic restrictions).

An exception to this is the extension in GNU C that allows global variabels
to be placed in registers. Here the programmer can do better than the
compiler, since the compiler does not see the whole program.

Re: C is 'better' than Ada because...

[Tim Behrendsen]

Robert Dewar <dewar@cs.nyu.edu> wrote in article
<dewar.838699292@schonberg>...
> Sandy said
> 
> "   The one big advantage C has traditionally had over other
>    languages is efficient compilation.  The reason is that 'C' is one
>    of the few languages that provides concepts such as register
>    variables to give hints to the compiler."
> 
> 
> This is incorrect. In practice the register declarations are useless to
> a modern optimizing compiler, and merely represent an unuseful attempt
> to intefere with choices that the compiler can make better anyway. Most
> modern C compilers, including gcc, pretty much ignore register
declarations
> (they cannot be completely ignored, since they introduce some (rather
ugly)
> semantic restrictions).
> 
> An exception to this is the extension in GNU C that allows global
variabels
> to be placed in registers. Here the programmer can do better than the
> compiler, since the compiler does not see the whole program.

Let me retract the register variable thing ... that is one of the
things compilers can do a halfway decent job on, and it doesn't
make my point very well anyway.  What's more important is the
very powerful C expression syntax where I can write expressions
that are easily optimized, and the ability to have very
close-to-the-metal pointers.

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[Tim Behrendsen]

On Thu, 1 Aug 1996, Keith Thompson wrote:

> In comp.lang.ada you write:
> 
> I don't believe C's expression syntax or close-to-the-metal pointers are
> particularly good for optimization.  They're good for making it easy to
> do straightforward compilation, and allowing source-level optimization.
> This made a lot of sense back when C was first developed.
> 
> An optimizing compiler typically has to build up some fairly high-level
> information about the structure of the program.  It then analyzes this
> structure, rearranges it for greater speed and/or smaller code size,
> and generates executable code (or assembly language, or whatever).
> If the language uses a lot of very low-level constructs, the compiler
> has to synthesize the higher-level information.
> 
> [interesting optimization examples snipped for brevity]

Unfortunately, it's very difficult to find good examples of things
that are difficult to optimize, because a case can always be made
for a specific optimization.  In my experience, optimizers are usually
strong in some areas, and weak in others.  Unfortunately, every one
is weak/strong in different areas.

Let me try this from a different direction.  Let's say I have the
theoretically perfect optimizer.  The perfect optimizer is capable of
taking HLL code and producing the absolute most efficient translation to
assembly.  It is not capable of improving the algorithms, of course;
a O(n^2) algoirthm is not going to improve to O(n).

Now, if I have a perfect optimizer I should be able to arrange my
code in *any* algorithmically valid sequence, and it will still produce
the same code by definition.  In fact, I should be able to toss in
red-herring code and it will drop out because it adds nothing to
the algorithm.

OK ... back to the real world.  We know that this isn't the case, and
we have to use *some* responsibility when coding our programs to not
doing something so boneheaded that the optimizer can't save us.

So, here's the question, then.  Where is the middle ground?  Given that
optimizers do not approach the ideal, how does a programmer know what's
going to be optimized efficiently, and what isn't?  I submit that it's
valuable to for a language to be capable of structuring the syntax such
that the optimizer can do straightforward job on it.

The thing about C is that the syntax is so loose and fast, naively coded
subroutines can defeat the optimizer just from the side effects.  How
about this; I'm just thinking off the top of my head, but perhaps there
is a "range of optimization" for a language.  Given a language, the
syntax has a certain range of flexibility.  For the C language, it is
extremely flexible in the number of ways something can be coded.  This
produces a wide range of optimization efficiency.

Would it be fair to say that Ada has less structural flexibility, but
you gain more consistency in optimization?  If this were true, then
it could be said that a carefully programmed C program could potentially
be faster, but the skill level required for the average optimization
efficiency for C is much higher than Ada (or another more rigid language).

The above is off the top of my head; does any of that make any sense?

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

I think that anybody who depends on optimization to make their code work or to
make it efficient is barking up the wrong tree.  Except for unusual
circumstances (e.g., embedded code), one should write straightforward, easily
debugged/tested/modified code.  Once the code works, *then* you turn on the
optimizers (and test again).  If the code isn't fast enough, first look for a
better algorithm.  Barring that, look at the code produced and see what the
compiler's problem is, and what alternate/equivalent code can be used to help
the compiler.  This latter is rarely necessary, and usually under exotic
circumstances.

-- 
#include <standard_disclaimer.h>
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: is Ada 'better' than C? (Was: Re: C is 'better' than Ada because...)

[Antoine Leca]

Kevin D. Quitt wrote:
> 
> I think that anybody who depends on optimization to make their code work

It seems clear that a code which work with optimisations on and don't work 
when they're off is brocken, isn't it?

> or to make it efficient is barking up the wrong tree. 

Ah ah.  This's not the same.
For me, an optimizer is clearly the tool you need when you're seeking
efficiency. (Really, it is "one of the tools".  Knuth's over algorithmics
is another, more important :-)

> Except for unusual
> circumstances (e.g., embedded code), one should write straightforward, easily
> debugged/tested/modified code. 

Full OK with you here.  You could add "maintainable" if it sounded English.

> Once the code works, *then* you turn on the optimizers (and test again). 

OK again.  For much code, I don't think this step is necessary.

> If the code isn't fast enough, first look for a better algorithm. 

Oh yes !

> Barring that, look at the code produced and see what the
> compiler's problem is, and what alternate/equivalent code can be used to help
> the compiler.  This latter is rarely necessary, and usually under exotic
> circumstances.

Very rarely, IMHO.
For doing that, you need a good knowledge of the arcanes of the machine (this is
not given to everyone, nor it seems necessary to me).  And to be of useful help
you must understand why the compiler has produced the actual output, i.e. to
understand the internal mechanisms of the compiler.  Moreover, to actually help
the compiler, you'd to be even more "clever" by knowing what each differences 
will make to the output, thus knowing how the compiler reacts to each source 
layout. (Kevin, "you" above doesn't mean yourself, of course)

To me, this is not the right way for programming efficiency _as a whole_.
Your scheme drives to a world where _all_ programmers must be experts in compiler
theory (admittedly, all programmers involved with efficiency).  I don't feel like
it: for me, it is much better to have compilers writters that do a better job
while writting "cleverer" optimizers, perhaps at the cost of compile time, than
to teach every programmers how to hardcode an over-optimisation of the output
code.

What I don't clearly see is whether C or Ada (or whatever else) is better or worse
in the process of writing optimizers and improving them.
Advantages of C are the small size of the language (not the same with C++ :) and
its broad audience, which drives biggers teams of compilers writters to the point.
Advantages of Ada are the fewest number of side effects or branches, which help to
compute execution paths.
The demonstration is difficult, because it can't be made on code provided by gurus
(we all know that one can provide an algorithm biased toward one or other language)
but instead on actual "production" code...
Open question.


Antoine Leca

Re: is Ada 'better' than C? (Was: Re: C is 'better' than Ada because...)

[Kevin D. Quitt]

On Tue, 06 Aug 1996 10:56:41 +0200, Antoine Leca <Antoine.Leca@Renault.Fr>
wrote:

>Kevin D. Quitt wrote:
>> I think that anybody who depends on optimization to make their code work
>It seems clear that a code which work with optimisations on and don't work 
>when they're off is brocken, isn't it?

Unless you're talking about timing being a factor.


>> or to make it efficient is barking up the wrong tree. 
>Ah ah.  This's not the same.
>For me, an optimizer is clearly the tool you need when you're seeking
>efficiency. 

For me, an optimizer is the tool to use to avoid gross deficiencies in the
compiler and code, and to make certain judgements about what works best on the
hardware.  For efficiency, we agree, one chooses one's algorithms carefully.


>> Except for unusual
>> circumstances (e.g., embedded code), one should write straightforward, easily
>> debugged/tested/modified code. 
>Full OK with you here.  You could add "maintainable" if it sounded English.

debugged/tested/maintained/modified.



>> Once the code works, *then* you turn on the optimizers (and test again). 
>OK again.  For much code, I don't think this step is necessary.

Agreed.  Optimizer technology is fairly reasonable nowadays.  I haven't had
one break my code in a little while.


>> Barring that, look at the code produced and see what the
>> compiler's problem is, and what alternate/equivalent code can be used to help
>> the compiler.  This latter is rarely necessary, and usually under exotic
>> circumstances.
>
>Very rarely, IMHO.

True, but I just had to do that for the code I work on for the Cassini
spacecraft.  The optimizer (source unidentified to protect the innocent -
i.e., me), was what I call a pessimizing cross-compiler (for the 8085).  I had
12K of ROM, and when I inherited the code, it compiled to 13K, and was only
about 10% functional.  I had to determine which C constructs generated what
code, and merely by changing the idiom of the code, I reduced it to less than
half the size.

>you need a good knowledge of the arcanes of the machine	- agreed
>(this is not given to everyone, nor it seems necessary to me).	- agreed
>And to be of useful help
>you must understand why the compiler has produced the actual output, i.e. to
>understand the internal mechanisms of the compiler.  Moreover, to actually help
>the compiler, you'd to be even more "clever" by knowing what each differences 
>will make to the output, thus knowing how the compiler reacts to each source 
>layout. (Kevin, "you" above doesn't mean yourself, of course)

The output of this compiler was pretty straightforward, with very little
optimization, and none from line-to-line; so I could and did easily determine
what the output would be for a given line of code.


>To me, this is not the right way for programming efficiency _as a whole_.

Hallelujah!


>Your scheme drives to a world where _all_ programmers must be experts in compiler
>theory (admittedly, all programmers involved with efficiency).  I don't feel like
>it: for me, it is much better to have compilers writters that do a better job
>while writting "cleverer" optimizers, perhaps at the cost of compile time, than
>to teach every programmers how to hardcode an over-optimisation of the output
>code.

I believe it's always best to be completely familiar with one's tools if one
expects to be the best possible at one's trade.  What you say is true for most
programmers, but I don't consider most programmers to be particularly good.
(That's no different than most of *any* profession; I'm not just picking on
programmers.  90% of *everything* is crud.)


>What I don't clearly see is whether C or Ada (or whatever else) is better or worse
>in the process of writing optimizers and improving them.
>Advantages of C are the small size of the language (not the same with C++ :) and
>its broad audience, which drives biggers teams of compilers writters to the point.

(This latter is why COBOL's ungainly source produces truly high-quality
executables.  All the man-years of work on the compilers and optimizers.)


>Advantages of Ada are the fewest number of side effects or branches, which help to
>compute execution paths.

Pointer aliasing kills most of the best optimizations possible.  Ada doesn't
have that problem.  Some C compilers now come with a switch that tells the
optimizer you're promising you haven't done any pointer aliasing.


>The demonstration is difficult

Part of my bias is that I'm an old hat, close-to-the-metal programmer.  I
resent any language features that "protect" me from the sharp edges by not
letting me near them.

-- 
#include <standard_disclaimer.h>
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Ralph Silverman]

William Clodius (clodius@hotspec.lanl.gov) wrote:
: In article <01bb7bfc$3c5ca460$96ee6fcf@timhome2> "Tim Behrendsen"
: <tim@airshields.com> writes: 

:    Ken Garlington <garlingtonke@lmtas.lmco.com> wrote in article
:    <31EF7E48.5ABE@lmtas.lmco.com>...
:    > Sandy McPherson wrote:
:    > > and produce efficient machine code.
:    > 
:    > Why is this an advantage of C over Ada? Ada certainly produces efficient
:    > machine code, given a good compiler. In fact, there are examples of Ada
:    > outperforming C with regard to efficiency.

:    The one big advantage C has traditionally had over other
:    languages is efficient compilation.  The reason is that 'C' is one
:    of the few languages that provides concepts such as register
:    variables to give hints to the compiler.

: This ignores Garlington's reply. If this was important, why do
: languages such as Ada, Fortran, Sisal, etc., often generate more
: efficient code than C athough they lack that hint?  On heavily
: pipelined processors, register scheduling is such a complex task that
: the human analysis is rarely useful and that hint is almost uniformly
: ignored. As to compiler speed, while C's coding brevity helps some
: aspects of compilation, its typical reliance on macros and the details
: of its declaration syntax result in a language that is harder to
: compile than some other languages such as Oberon.

:    Yes, you can wave your hand and say, "well, the compiler
:    should take care of that".  But then, reality rears its head, and
:    we realize that there are *no* compilers that are that smart.
:    Here's an old saying that I just made up ...

:    Behrendsen's Law: "All optimizers are crap."

:    We will never have an optimizer that can do as good a job
:    as human optimization until we get "strong AI", but that would
:    take an actual science of AI to exist (let's not get started on
:    *that*!).  C is one of few languages that recognizes this.

: While on modern processors a human can still compete with a compiler
: on small pieces of code, provided he works directly in assembler,
: doing that on every portion of a significant code is too exhausting
: for humans. C is no substitute for assembler in such cases. The
: aspects of C that are thought of as resembling assembler, either loose
: semantic information usefull for global analysis, e.g., the
: distinction between pointers and arrays, or are shorthands for
: constructs, e.g., i=i+1, that are easily recognized by any compiler.

:    Since C is such a small language, this also makes it
:    easier for the compiler/optimizer to a (relatively) good job.

: Most compilers nowadays use backends that are common among several
: languages, and most optimizations are performed in the language
: independent backends.  The size of the language has relatively little
: effect on optimization compared to the detailed semantics of the
: language. Strong typing in any language helps with optimization, and
: both C and Ada (indeed many other languages) have strong
: typing. Unfortunately, while C is a small language, its reliance on
: pointers and side effects introduces optimization problems not present
: in many other languages, e.g, Ada, Fortran, Sisal, etc.
: -- 

: William B. Clodius		Phone: (505)-665-9370
: Los Alamos National Laboratory	Email: wclodius@lanl.gov
: Los Alamos, NM 87545

--
**************begin r.s. response***************

	1) re.  optimizers...
	   this is puzzling...
	   certainly these work quite well generally...
	   and,  generally,  are far better than nothing!!!

	   (by the way
	    ((ms pc dr)dos) 'c' language development system,
	    (SHAREWARE) hi-tech pacific ppd (v7.50)
	    includes a remarkable optimizer.)

	2) certainly,  increasingly,
	   computer programming is automated,
	   and the old hand-crafted cool stunts
	   become increasingly redundant,
	   as,  generally,  in work increasingly
	   automated...

	   the advantages cited re.
		the 'c' programming language
	   relate largely to the origins of this
	   in 'the old days'.

	   the reaction...
		retro programming
		^^^^^^^^^^^^^^^^^
	   as with
		'wooden ships and iron men'
	   ,
	    is coming...
	    or,  perhaps,  already here...

	   like tall ships to train elite cadets...
	   and/or surviving as a folk craft...

**************end r.s. response*****************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: C is 'better' than Ada because...

[William Clodius]

In article <01bb7e2f$aeef4660$87ee6fce@timpent.airshields.com> "Tim
Behrendsen" <tim@airshields.com> writes: 

<snip>

   I'm not going to claim to have used every compiler, obviously, but
   I base this opinion on often viewing the assembly language output when
   I get a core dump or during debugging sessions.  Now, I've used a lot
   of assembly language, so I usually write my C code to be easy on the
   optimizer (use pointers when needed rather indexes, for example), and
   I admit that sometimes optimizers are very good.  The problem is, the
   compiler often doesn't have enough contextual information to know what
   to do compared to the human writing the program, which bring us to ...

There is no reason why a good compiler should generate worse code for
an array access than for a pointer access. An array can be constructed
by the compiler as a single block of memory whose access via indices
is the same as through a pointer. Au contraire, because a pointer can
be associated with any object of compatible type the analysis for a
highly optimizing compiler is more difficult with pointers than with
arrays. The problem with arrays in C is their lack of flexibility in
term of dynamic memory allocation, that if they are associated with a
pointer at any point in the scope alias analysis becomes more
compicated for the compiler, and that when pased as an argument
to a user defined function they are not distinguished from pointers.

   Global optimization: The compiler can often make decisions better
   than the human can because of the large scope of global optimizations,
   but again, the information needed to know when certain areas are
   going to be used a lot versus other areas is not known at compile
   time, which moves us to ...

Most compilers, the ones O'Keefe cites are exceptions, do relatively
little global analysis. O'Keefe's were developed for languages that
would otherwise be extremely difficult to optimize. Many languages
need much less global information for the most useful optimizations,
due to the presence of typing, data type structure, side effect, and
aliasing information that is required in standard conforming
code. Standard conforming C code provide the essential typing and data
structure information, but does not provide full side effect and
aliasing information, so that it is intermediate in optimizability.

   Run time profiling/compiler feedback: This can certainly provide
   good information back to the compiler, but it seems a little
   dangerous.  I have not used this type of optimization, so my
   opinion means little in this case, except for just my general
   impression.  Anything other than a trivial program is going
   to be very difficult to simulate real-world conditions in order
   to get an optimal result.  The downside is if your test conditions
   are wrong, you may end up with a "most pessimum" optimization.

But if your test conditions are wrong you have typically not
appropriately tested all aspects of the code, including the
correctness of its output, its robustness, and its general
efficiency.

   It just seems to me that there is no substitute for a well
   thought-out design.  Depending on the compiler to save bad design
   is just a bad idea.

True, a compiler will not change a 0(n*n) algorithm to a 0(n*ln(n))
algorithm, but it can have a significant effect on the multiplicative
factor. Further, probably every language has limitations in terms of
expressibility of design. Algorithms that are essentially independent
of data type, e.g., lists, are difficult to specify in a type
independent form in languages such as C, and must be reimplemented for
each new special case. Aspects of the design that are independent of
the details of the implementation, but can be used by the compiler for
optimization, e.g., that a list wil not be cyclic or that an object
will not be modified after its creation, are also difficult to express
in C, and many other commonly used languages.

<snip>

   The above are all worthwhile opimizations; I'm not claiming that
   optimizers do nothing.  All I'm saying is that too often programmers
   fall back on the lazy line, "Oh well, the compiler should take care
   of that."  For example, if I have ...

   for (i = 0; i < 10000000; ++i) 
       array[i] *= abs(values[i]);

   Should I be *sure* this is going to be done efficiently, and use
   pointers, or should I just let the compiler handle it? I say that
   a competent programmer should use pointers out of habit, because
   its just good design and practice.  And when the problem becomes
   less trivial than the one above, the programmer will already be
   using the proper techniques *the first time*, rather than having
   to go back and fix the inevitable performance bottlenecks.

Again a good compiler, if anything, should generate better code for an
array than for a pointer.

   I think you are being too optimistic that optimizers produce
   better code than "almost every programmer there is".  If that were
   true, then projects would *never* be written in assembly language.

   As it stands, we know that often times things are written in
   assembly for performance reasons, such as device drivers.
   The perfect example of this are computer games.  If your theory
   were true, then they would all be written in high-level languages
   to gain the best performance.  We know that this isn't the case,
   however.  A bright human can always outdo the optimizer.

Again history affects useage. First, the most efficient code
generators are produced first in a research environment, and only
propagate to commercial compilers after their robustness has been
thoroughly tested. Second, we rarely judge anything without the
predjudices of our years of experience. People typically expect what
was standard when they first started in a field, not what is currently
standard. Optimizers are typically better now than they were ten years
ago. Third, users do not always put a large emphasis on general code
efficiency. For example, the original Fortran I and II compilers used
a number of optimizations that were not used in any other compilers,
Fortran or otherwise, untill the late sixties, and were only common in
compilers by the mid to late seventies. Fourth, while high level
languages are not commonly used for such tasks they are becoming more
commonly used for such tasks, Erlang in particular comes to mind.

   > And you know what?  C is one of the *harder* languages to optimise!

   You are probably right, if you let the optimizer handle everything.
   But C also gives the capability to do things such as ...

   if ((array[++n] = GetValue(arg)) != 0) {
       ....

   v.s. a typical non-C language ...

   n = n + 1;
   array[n] = GetValue(arg);
   if (array[n] != 0) {
       ...
   }

   Now, which is easier to optimize?  For this trivial case, a
   modern compiler would probably do exactly the same thing, but
   what about when it starts getting non-trivial?  If I code my
   expressions to take advantage of the "data flow" nature of C's
   syntax, I can make it very easy for the optimizer to do a
   great job.  And it's not any more work, it's just a matter of
   experience and living in reality, and not pretending that the
   compiler is smarter than it really is.

Actually C has relatively little in the way of data flow concepts as
data flow is commonly understood. A true data flow language would
avoid side effects in almost every context except I/O. Your example is
full of side effects, some of which, particularly GetValue(arg), are
difficult to optimize. Depending on the context a data flow language
might have the syntax

array[1:n] = GetValye(arg(1:n));
where (array /= 0) { ... }

in the above GetValue is required to not have side effects so that the
definition 

array[1:n] = GetValye(arg(1:n));

can be understood as occuring in parallel. In C for full optimization
the compiler has to determine that arg is not aliased with elements of
array, and that GetValue has no side effects. Note that a highly
pipelined architecture is comparable to a truly parallel architecture
in many optimization issues.
-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545

Re: C is 'better' than Ada because...

[Tim Behrendsen]

William Clodius <clodius@hotspec.lanl.gov> wrote in article 
> There is no reason why a good compiler should generate worse code for
> an array access than for a pointer access. An array can be constructed
> by the compiler as a single block of memory whose access via indices
> is the same as through a pointer. Au contraire, because a pointer can
> be associated with any object of compatible type the analysis for a
> highly optimizing compiler is more difficult with pointers than with
> arrays. The problem with arrays in C is their lack of flexibility in
> term of dynamic memory allocation, that if they are associated with a
> pointer at any point in the scope alias analysis becomes more
> compicated for the compiler, and that when pased as an argument
> to a user defined function they are not distinguished from pointers.

I normally use IBM's C compiler under AIX.  I'm not sure where it
fits in the scheme of things, but it seems to do a pretty decent
job optimizing.

I had an [ex-]employee who wrote the slowest code on the face of
the earth.  Because of performance problems in our application,
I went through and analyzed his code.  The man almost never used
pointers, and almost always used array accesses.  These algorithms
were much more complex that the trivial examples we've been
talking about.

I rewrote the subroutines to use pointers, and with an eye toward
easy optimization by the compiler.  The algorithms used were
exactly the same; I just reworked the stylistic expression of them.
I didn't view the assembly language output, or anything processor
specific like that.  I simply coded things in a straightforward
data-flow sort of way, keeping the amount of context information
that the compiler needed at any one point in the subroutine to
a minimum.

I was easily able to get 3-4x performance improvements.

My point is that, yes, optimizers can do a good job in certain
circumstances, but out in the real world with very complex
subroutines, there is only so much that is possible.  Perhaps
I've only used compilers with bad optimizers, but isn't it
better to code programs for straightforward optimization and
not depend on what goes on behind the scenes?  Who goes back
and checks what the compiler produced? At least until you
begin profiling the program to figure out why the darn thing
is so slow ...

>   Run time profiling/compiler feedback: This can certainly provide
>   good information back to the compiler, but it seems a little
>   dangerous.  I have not used this type of optimization, so my
>   opinion means little in this case, except for just my general
>   impression.  Anything other than a trivial program is going
>   to be very difficult to simulate real-world conditions in order
>   to get an optimal result.  The downside is if your test conditions
>   are wrong, you may end up with a "most pessimum" optimization.
>
> But if your test conditions are wrong you have typically not
> appropriately tested all aspects of the code, including the
> correctness of its output, its robustness, and its general
> efficiency.

I disagree; I can test all the code paths without them necessarily
being executed the relative number of times that a real world
test would bring.  Take a relational DBMS; I can test all of the
SQL constructs that may be supported, but that doesn't mean that
I have real-world databases at my disposal in order to general
code optimization statistics.

> Actually C has relatively little in the way of data flow concepts as
> data flow is commonly understood. A true data flow language would
> avoid side effects in almost every context except I/O. Your example is
> full of side effects, some of which, particularly GetValue(arg), are
> difficult to optimize. Depending on the context a data flow language
> might have the syntax
> 
> array[1:n] = GetValye(arg(1:n));
> where (array /= 0) { ... }
> 
> in the above GetValue is required to not have side effects so that the
> definition 
> 
> array[1:n] = GetValye(arg(1:n));
> 
> can be understood as occuring in parallel. In C for full optimization
> the compiler has to determine that arg is not aliased with elements of
> array, and that GetValue has no side effects. Note that a highly
> pipelined architecture is comparable to a truly parallel architecture
> in many optimization issues.

I would imagine that C would rather stink when it comes to
automated parallization (but then, what doesn't?).  Ordering a
pipeline is much less complex of a problem that parallelizing
an algorithm, though!  If I'm not mistaken, however, it used to
be the case the parallelizing compilers were primarily for
FORTRAN, because of it's very primitive (read: lack of side
effects) nature.  This is somewhat dated knowledge on my part,
though. There may be more sophisticated solutions out there
nowadays.

I guess my point is not that any construct in C is automatically
able to be optimized to the limit; it's that it's possible
to code things in such a way that it gets optimized very well.

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[Robert I. Eachus]

In article <01bb7e2f$aeef4660$87ee6fce@timpent.airshields.com> "Tim Behrendsen" <tim@airshields.com> writes:

  > The above are all worthwhile opimizations; I'm not claiming that
  > optimizers do nothing.  All I'm saying is that too often programmers
  > fall back on the lazy line, "Oh well, the compiler should take care
  > of that."  For example, if I have ...

  > for (i = 0; i < 10000000; ++i) 
  >     array[i] *= abs(values[i]);

  > Should I be *sure* this is going to be done efficiently, and use
  > pointers, or should I just let the compiler handle it? I say that
  > a competent programmer should use pointers out of habit, because
  > its just good design and practice.  And when the problem becomes
  > less trivial than the one above, the programmer will already be
  > using the proper techniques *the first time*, rather than having
  > to go back and fix the inevitable performance bottlenecks.

   Let's take that "little" example and ask a few of the questions
that a "good" optimizer will consider:

   1.  Should I have two pointers or three?  The value of array[i]
needs to be fetched, then multiplied by abs(values[i]), then stored.
If I use only two address registers then on many architectures there
will be a pipeline stall.  On many RISC architectures, I can put the
increment of the pointer to array before the RHS evaluation and store
to pointer - 1, but other architectures do not allow negative offsets,
so you run the pointer from address(array[0]) - 4 to
address(array[1000000]) - 4. (Or whatever the length of the elements
is. Strength reduction and constant folding are assumed.)  On some
RISC hardware you can do full range register offsets, so you do (in a
fairly obvious intermediate code):

      LOAD(R1,address(values))
      LOAD(R2,address(array))
      LOAD(R3,0)
      LOAD(R4,-4)
      ADD(R4,R1)
      LOAD(R5,4000000)
    <L1>
      LOAD(R6,(R1(R3))
      LOAD(R7,(R2(R3))
      ADD(R3,4)
      ABS(R6)
      MULT(R7,R4(R3))
      BNE(R3,R5, L1)
      STORE(R7,@R4)
      ...

      Or some such.  Notice that this code corresponds to source code
that does NOT use pointers, and it takes fairly sophisticated analysis
to get here from code using pointers and doing two increments.

    2. How many times should I unroll the loop?

    3. Can I get better results by prefetching array elements so the
cache is always full?

    4. If this machine doesn't have a write-through cache or a deep
write pipe, can I design the code so that two array elements are
generated in a register pair and written together?  (Just because the
double precision write was intended for double precision floating
results, doesn't mean you can't use it elsewhere.)

    5. If this machine has more than one integer arithmetic pipeline,
should I use one for offsets and the other for arithmetic, or (more
likely) evaluate two elements of the array at once?

    Now, how many of those optimizations did you think of?  And how
many do you want to embed in your source code?  (I hope the second
answer is none.)

    Let me tell you a story, shortened for this forum.  I got a call
that our compiler was generating "junk" code for an Ada subroutine.  I
looked at the source, which went on for over a page, and suggested an
equivalent which took one line.  The guy promised to try that and call
me back.

    "It generates the same three junk instructions!"  He complained.

    "Oh, what's wrong with them they look fine to me?"

    "You can't do that in that few instructions!"

    "Let's see, the first instruction predecrements the stack
pointer...why is it doing that?  Oh, so it can do an indirect fetch
through the second parameter.  The second instruction adds the first
parameter, why no test for overflow?  Ah, analysis must show that it
can never happen?  Right.  Now, the third instruction stores the
result where it got the first operand, carefully postincrementing the
stack pointer so it will be right in the return.  What's wrong with
that?"

     "Do you really think the compiler should be messing with the
stack pointer like that?"

     "Why not, you can't get a trap where it is wrong."

     "But how does the compiler know that?"

     "It does a global call tree, and attaches known bounds to every
parameter for procedures not visible outside the unit.  If you put a
declaration in the package spec, you should get the code you expect."

     "Oh."

      Now, I thought the peephole optimization that didn't know what a
stack pointer was, just when its value had to be trustworthy was cool
stuff...in 1984.  There are lots better optimizers and code generators
around now.  For almost any chip of interest, Power PC, Pentium,
Pentium Pro, 680x0, SPARC, HPPA, etc., the optimizer is capable of
doing incredible things if it knows the specific target version.  You
should never want to write code that finely tuned to the hardware, but
a good optimizer can gain 50% or more improvement by knowing the
specific chip model.

     A horrible example, but very true.  I've worked with compilers
which generated different calling sequences for 68020, 68030, and
68040.  All link time compatible, but the differences in number of
clocks for certain instructions meant that the best sequence was
different on different processors.  And, if you care, the 68040
sequence looked the dumbest, because it was dominated by memory
fetches, so fewer instructions, fewer fetches--it actually used the
the CALLM instruction.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: C is 'better' than Ada because...

[David Wheeler]

In article <01bb7e2f$aeef4660$87ee6fce@timpent.airshields.com> "Tim Behrendsen" <tim@airshields.com> writes:

:   > The above are all worthwhile opimizations; I'm not claiming that
:   > optimizers do nothing.  All I'm saying is that too often programmers
:   > fall back on the lazy line, "Oh well, the compiler should take care
:   > of that."  For example, if I have ...

:   > for (i = 0; i < 10000000; ++i) 
:   >     array[i] *= abs(values[i]);

:   > Should I be *sure* this is going to be done efficiently, and use
:   > pointers, or should I just let the compiler handle it? I say that
:   > a competent programmer should use pointers out of habit, because
:   > its just good design and practice.

Actually, the assumption that C pointers always (or even usually)
generate better machine code is an urban legend.  On many
computer/compiler combinations, using arrays generally yields BETTER
performance.  This isn't just a recent occurance -- I changed C code
running on 8086's from using pointers to using arrays and produced
noticeable improvements.  This was a stupid C compiler, too.  AND I've
found that arrays are less likely to have bugs in them.

When you're _really_ concerned about performance, try different
approaches and MEASURE.  If you aren't measuring, then you aren't
very concerned about performance.  Code that gives the optimizer more
information (e.g. arrays not pointers) will often give better results
because it gives the optimizer more information to work with.  Sometimes
that isn't true, which is one reason why you need to measure.

If you're interested in performance, take a gander at the example
where a novice Ada coder beat experienced assembly language programmers (!)
because the optimizer could try out more approaches than the experts:
 [Elam 1992] Elam and Lawlis.  March 1992.  ``Ada Whips Assembly''.
   "http://www.seas.gwu.edu/seas/eecs/Research/ada/lawlis.html"

--- David

Re: C is 'better' than Ada because...

[Olivier Devuns @pulsar]

eachus@spectre.mitre.org (Robert I. Eachus) writes:

[snip]

>	A horrible example, but very true.  I've worked with compilers
>   which generated different calling sequences for 68020, 68030, and
>   68040.  All link time compatible, but the differences in number of
>   clocks for certain instructions meant that the best sequence was
>   different on different processors.  And, if you care, the 68040
>   sequence looked the dumbest, because it was dominated by memory
>   fetches, so fewer instructions, fewer fetches--it actually used the
>   the CALLM instruction.


Horrible indeed ! The CALLM instruction exists only on the '020 ... Your poor
'040 must have worked hard to emulate it ;-) !

--
Olivier Devuns -- devuns@thomsoft.com  | Thomson Software Products
   "Views expressed are my own"        |      San Diego, CA
                                       |  http://www.thomsoft.com

Ada 95 is a FREE language (was: C is 'better' than Ada because...)

[Laurent Guerby]

Craig> Well I'm not an Ada expert, but I have "Ada as a Second
Craig> Language" by Norman Cohen and "Ada Programmer Handbook" by Dean
Craig> Gonzalez.  On the cover a little R with a circle around it
Craig> appears by the word Ada. In the book by Norman Cohen it states
Craig> (page 8) that the name "Ada" is a trade mark of the DOD and
Craig> it's usage is "strictly enforced". I take that to mean that if
Craig> it doesn't conform it *can not* be called an Ada compiler. It
Craig> states you can work towards conformity and use the name, but
Craig> thats an exeption.

Craig> If I were to bid on a contract, tell the DOD I'm developing in
Craig> Ada and submit C++, I think they would call that "fraud".

Craig> I think part of the resistance to Ada is C belongs to the
Craig> world.  Ada belongs to the government! :-)

Craig> If this has changed, please enlighten me!

   1. You're talking about 83 (13 years old now).
   2. Ada is now Ada 95 (buy new editions of your books).
   3. The US government no longer owns the name Ada, there's no need
      to put an (R).
   4. The ANSI/ISO/X standards for both Ada 83 and Ada 95 are free and
      freely available in various electronic formats. (This is an
      exception in the standard world.)
   5. There is a GNU compiler for Ada 95, source copyrights assigned
      to the Free Software Fundation.
   6. Megabytes of free Ada source code are available in various
      repositories.
   7. Free Ada tutorials and books (eg: Ada Quality & Style) are
      available.

   To summarize, for $0 (or for the price of a CD-ROM), you have
everything you need to write Ada 95 programs (even distributed
programs) on plenty of platforms, and sources to hack your compiler
(or your Ada library).

   Welcome in the 1996 real world, Craig (and you've now everything
you need to become an official Ada expert ;-).

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <4uj42h$j06@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> Richard Riehle <rriehle@nunic.nu.edu> wrote:
> 
> >  C++ and C are probably fine for certain classes of problems, but they
> >  are certainly archaic when compared to the progress being made in
> >  the world of programming languages. And I do not refer only to Ada in
> >  that last sentence.  Eiffel also comes to mind as a preferred
> >  alternative to C++.
> 
> 
> I agree with that, if you include PC programming as "a certain class of 
> problems". Most PC OS's are written in C/C++. It makes sense that
> applications would then be coded in C/C++ as well. Pascal has more 

Well you didn't say "should", so I suppose this really just means that
coding apps in C/C++ on such platforms makes more or less the same amount
of sense as coding them in anything else, i.e., the point is irrelevant.
If you did mean "should", you should rethink the issue.


> support than Ada does in this area. I don't know of a vendor supporting
> those platforms in Ada as well as is done with C/C++. So you go with
> C/C++ due to the quality of the impementation, not the language.

Oh, I dunno about that.  Check out the Tomson ObjectAda offering.


> I would also like to point out that technical superiority is not always
> a good indicator of success. Even if Ada is "better" than C++ that does
> not indicate it will replace it in area's where C/C++ is now domanant.

Agreed.  This is mostly a "social" issue.  Conservative programmers not
wanting to learn new things, wannabe managers knee-jerk following of fads,
etc.

> Realize it's much easier get a C compiler up and running for an embedded
> system that it is an Ada compiler. To even call it an Ada compiler it 
> must pass a validation suite. 

First point: Why do you think this?  There seems to be quite a lot of
evidence indicating that this is not true.

Second point.  Just plain wrong.  If you want, you can call your C++
compiler an Ada compiler.  Of course, no one will take you seriously,
but you are free to do so.


> The problem information systems managers have is today you must
> incorporate PC users. Why develope a schizophrenic additute of doing
> one with the domant tool (C/C++) and the other with Ada?

Maybe.  But then why not switch completely to Ada?  We are not using
C++ for anything and C only if it makes some sense (have not found that
yet) and are exclusively in Ada.  And we are on PC platforms and will
soon be much more in this environment and see no obstacle.


>I can see keeping working in COBOL, but if you were to switch, switch
> to C++.

First, there is not likely a sufficient reason to switch in such a
case (as you seem to agree).  But if you did, C++ would be the last
thing to switch to as it is about as foreign to COBOL as water is to
oil.  It just makes no sense.  Smalltalk would probably be the more
intelligent thing to go with.


> I don't think AT&T is going to start coding thier switching systems 
> in Ada just because it a better language, either.

Sad but true.  But then, they are the quintessential "old dog"...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Craig Franck]

jsa@alexandria (Jon S Anthony) wrote:
>In article <4uj42h$j06@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <
>> Realize it's much easier get a C compiler up and running for an embedded
>> system that it is an Ada compiler. To even call it an Ada compiler it 
>> must pass a validation suite. 
>
>First point: Why do you think this?  There seems to be quite a lot of
>evidence indicating that this is not true.
>
>Second point.  Just plain wrong.  If you want, you can call your C++
>compiler an Ada compiler.  Of course, no one will take you seriously,
>but you are free to do so.

Well I'm not an Ada expert, but I have "Ada as a Second Language"
by Norman Cohen and "Ada Programmer Handbook" by Dean Gonzalez.
On the cover a little R with a circle around it appears by the 
word Ada. In the book by Norman Cohen it states (page 8) that 
the name "Ada" is a trade mark of the DOD and it's usage is 
"strictly enforced". I take that to mean that if it doesn't 
conform it *can not* be called an Ada compiler. It states you
can work towards conformity and use the name, but thats an exeption.

If I were to bid on a contract, tell the DOD I'm developing in Ada
and submit C++, I think they would call that "fraud". 

I think part of the resistance to Ada is C belongs to the world.
Ada belongs to the government! :-)

If this has changed, please enlighten me!
 

Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[James A. Squire]

Craig Franck wrote:
> 
> jsa@alexandria (Jon S Anthony) wrote:
> >In article <4uj42h$j06@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <
> >> Realize it's much easier get a C compiler up and running for an embedded
> >> system that it is an Ada compiler. To even call it an Ada compiler it
> >> must pass a validation suite.

If you are bidding on a government contract, yes.  Otherwise, no.

> conform it *can not* be called an Ada compiler. It states you
> can work towards conformity and use the name, but thats an exeption.

And that is a problem for the vendor, not for you.  Most likely they
already are working towards validation, but you don't need to worry
about that.

> If I were to bid on a contract, tell the DOD I'm developing in Ada
> and submit C++, I think they would call that "fraud".

Are you?  If not, then this is irrelevent to this discussion.  The
question is, which language is better.

> I think part of the resistance to Ada is C belongs to the world.
> Ada belongs to the government! :-)

Yesterday's news.  Today this is no longer true, conceptually.
Implementation may take awhile yet, but the Ada language is going
commercial.  Count on it.
-- 
James Squire                             mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com/
Opinions expressed here are my own and NOT my company's
"I will teach you."
'About yourself?'
"About you. Until you are ready."
'For what?'
"To fight legends."
        -- Kosh and Sheridan, "Hunter, Prey"

Re: C is 'better' than Ada because...

[Craig Franck]

"James A. Squire" <m193884@csehp3.mdc.com> wrote:
>Craig Franck wrote:

>> I think part of the resistance to Ada is C belongs to the world.
>> Ada belongs to the government! :-)
>
>Yesterday's news.  Today this is no longer true, conceptually.
>Implementation may take awhile yet, but the Ada language is going
>commercial.  Count on it.

You are correct. When I made this statement, I used as a referece
some old texts, that are clearly not up to date. Time to go to
Barnes & Noble and buy something on Ada 95! Perhaps that way my
comments will be more likely to correspond to the current state
of the language. 
 

Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[John Howard]

...AT&T employees created C and caused it to spread along with UNIX 
systems.  Since you work for AT&T I can see how you would be in the
minority there if you selected something other than C.  Does AT&T allow 
you the option of picking a better language for the job?  For example, a
job that required standardized multitasking support that the C dialects do 
not provide.  Read on below...

On 12 Aug 1996, Craig Franck wrote:
> Well I'm not an Ada expert, but I have "Ada as a Second Language"
> by Norman Cohen and "Ada Programmer Handbook" by Dean Gonzalez.
> On the cover a little R with a circle around it appears by the 
> word Ada. In the book by Norman Cohen it states (page 8) that 
> the name "Ada" is a trade mark of the DOD and it's usage is 
> "strictly enforced". I take that to mean that if it doesn't 
> conform it *can not* be called an Ada compiler. It states you
> can work towards conformity and use the name, but thats an exeption.

The second edition of "Ada as a Second Language" was released this year
and incorporates Ada 95.  The first edition you are using is from 1986.
On page 8 from the second edition, "a compiler can be called an Ada
compiler if it implements the core language".  The core language consists
of sections 1 through 13; annexes A, B and J of the Ada 95 Reference 
Manual v6.0.  The registered trademark symbol is no longer applied to the
word Ada.

> If I were to bid on a contract, tell the DOD I'm developing in Ada
> and submit C++, I think they would call that "fraud".

The contract would be more specific and indicate a standardized Ada
language such as the International Standard ANSI/ISO/IEC-8652:1995.

> I think part of the resistance to Ada is C belongs to the world.
> Ada belongs to the government! :-)

Which dialect of C belongs to the world?  I use UNIX services via an
online service provider but I don't program for it.  I mainly use a PC and 
OS/2 Warp (for DOS/Windows support too).  So which C dialect would you 
claim belongs to an OS/2 user or a Windows95 user?

Ada 95 clearly does not belong exclusively to our government.  GNU based 
Ada 95 compilers are available for free from cs.nyu.edu/pub/gnat.  You 
even receive the source code to GNAT.  Plus the Ada 95 Reference Manual 
and the Ada 95 Rationale book are free too.

> If this has changed, please enlighten me!

Alot has changed in ten years.  The C camp is being splintered off into 
Java and C++ camps now to get the benefits of classwide programming.  I 
witnessed the division of support over the years for the Pascal dialects. 
Borland Pascal users saw their pool of support get larger longer while
other Pascal pools dried up.  The chaos caused by lack of support for a
decent standardized language caused confusion and expense to the detriment
of all Pascal users.  In stark contrast, Ada 95 is the first 
internationally standardized object-oriented language.  Ada 95 is designed 
to not become obsolete.  I can invest into support for Ada 95 without
fearing it might be a wasted investment toward a dead-end.  I trust Ada 
95 is capable enough to do any job I want to work on.

The fact that a GNU C or GNU C++ can do a job generally means that a GNU 
Ada 95 can do the same job since they use the same GNU back-end compiler. 
Consequently, support for Ada 95 is not going to disappear provided GNAT 
is available for important operating systems and hardware platforms.

> clfranck@worldnet.att.net
> Manchester, NH

-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --

Re: C is 'better' than Ada because...

[Craig Franck]

John Howard <jhoward@sky.net> wrote:

>On 12 Aug 1996, Craig Franck wrote:
>> Well I'm not an Ada expert, but I have "Ada as a Second Language"
>> by Norman Cohen and "Ada Programmer Handbook" by Dean Gonzalez.
>> On the cover a little R with a circle around it appears by the 
>> word Ada. In the book by Norman Cohen it states (page 8) that 
>> the name "Ada" is a trade mark of the DOD and it's usage is 
>> "strictly enforced". I take that to mean that if it doesn't 
>> conform it *can not* be called an Ada compiler. It states you
>> can work towards conformity and use the name, but thats an exeption.
>
>The second edition of "Ada as a Second Language" was released this year
>and incorporates Ada 95.  The first edition you are using is from 1986.
>On page 8 from the second edition, "a compiler can be called an Ada
>compiler if it implements the core language".  The core language consists
>of sections 1 through 13; annexes A, B and J of the Ada 95 Reference 
>Manual v6.0.  The registered trademark symbol is no longer applied to the
>word Ada.

Thank you for pointing that out. I have since become aware that the 1986
edition is out of date and I shall find a more recent text to quote 
from.

>> I think part of the resistance to Ada is C belongs to the world.
>> Ada belongs to the government! :-)
>Which dialect of C belongs to the world?  I use UNIX services via an
>online service provider but I don't program for it.  I mainly use a PC and 
>OS/2 Warp (for DOS/Windows support too).  So which C dialect would you 
>claim belongs to an OS/2 user or a Windows95 user?

My statement was a hyperbole; an extravagant exaggeration. I can
not defend it in a literal sense. The fact the US government,
particularly as it relates to the Military Industrial Complex
had anything to do with the creation of Ada, makes me highly 
suspicous. But to say something is bad just because of where
it came from would be to commit the genetic fallacy of reasoning,
so I won't comment on that any futher.

>Ada 95 clearly does not belong exclusively to our government.  GNU based 
>Ada 95 compilers are available for free from cs.nyu.edu/pub/gnat.  You 
>even receive the source code to GNAT.  Plus the Ada 95 Reference Manual 
>and the Ada 95 Rationale book are free too.
>
>> If this has changed, please enlighten me!
>
>Alot has changed in ten years.  The C camp is being splintered off into 
>Java and C++ camps now to get the benefits of classwide programming.  I 
>witnessed the division of support over the years for the Pascal dialects. 
>Borland Pascal users saw their pool of support get larger longer while
>other Pascal pools dried up.  The chaos caused by lack of support for a
>decent standardized language caused confusion and expense to the detriment
>of all Pascal users.  

Wow! Sounds like a "Software Crisis"! ;-)

In stark contrast, Ada 95 is the first 
>internationally standardized object-oriented language.  Ada 95 is designed 
>to not become obsolete.  I can invest into support for Ada 95 without
>fearing it might be a wasted investment toward a dead-end.  I trust Ada 
>95 is capable enough to do any job I want to work on.
>
>The fact that a GNU C or GNU C++ can do a job generally means that a GNU 
>Ada 95 can do the same job since they use the same GNU back-end compiler. 
>Consequently, support for Ada 95 is not going to disappear provided GNAT 
>is available for important operating systems and hardware platforms.

I don't want support for Ada to disappear! I like Ada. I call it Pascal
on steriods. I don't want a Tower of Babel either. I think if a handfull
of languages dominate, that's enough standardization for me.
 

Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[Ken Garlington]

Craig Franck wrote:
> 
> The fact the US government,
> particularly as it relates to the Military Industrial Complex
> had anything to do with the creation of Ada, makes me highly
> suspicous.

(he said, using ARPA^H^H^H^HInternet.... :)

-- 
LMTAS - "Our Brand Means Quality"

Re: C is 'better' than Ada because...

[Craig Franck]

Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:
>Craig Franck wrote:
>> 
>> The fact the US government,
>> particularly as it relates to the Military Industrial Complex
>> had anything to do with the creation of Ada, makes me highly
>> suspicous.
>
>(he said, using ARPA^H^H^H^HInternet.... :)

That's true, and I am highly suspicious of the Internet! :-)
I believe it was in 1988 that the old 56kbps NSF network was
shut down. Ma Bell is my service provider. But yes, there is
no escaping! Someone told me that the TCP protocol data unit had an 
urgent flag, the use of which is determined by the application
layer. If you set it, certain highly fault tolerent
routers in secret government locations, would handle that 
packet and give it priority. That way if the Internet was 
under a coordited effort to shut it down, either through the
use of viruses or massive phyical distruction of resources, the
government's packets would still get through, even if everyone elses
did not. I asked him if I found a way to set it, would my Web
pages load faster, and he said it was top secret and couldn't
talk about it. I told him, "if it's top secret, why the hell did you 
bring it up in the first place?" Perhaps this belong over at 
comp.protocols.* over even alt.lunatic.fringe.  


Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[Stephen M O'Shaughnessy]

3.93.960812181242.15938A-100000@sky.net> <4uopmu$hod@mtinsc01-mgt.ops.worldnet.att.net> <32106C62.55B1@lmtas.lmco.com>
MIME-Version: 1.0

C code.
C code run.
Run, code, run.
Run, $@!!*%#@, run.

Re: C is 'better' than Ada because...

[Stephen M O'Shaughnessy]

Sorry, I could not help myself.  I saw this on a co-workers
chalkboard.  Kudos to the originator, who ever you are.

Re: C is 'better' than Ada because...

[Adam Beneschan]

gwinn@res.ray.com (Joe Gwinn) writes:

 >I believe you.  It sounds like you were there, and, as I said, I was
 >playing with blocks then.  Well, cars.  I once read an article claiming
 >that DoD-1 was the original name for what became COBOL, but had no direct
 >evidence.  Maybe, the "DoD-61" was clipped to "DoD-1" somewhere, and the
 >mistake stuck.  
 >
 >But, clearly, if COBOL was DoD-61, there must have been a DoD-1 before
 >COBOL, so Ada cannot be the first to have been called DoD-1.

It's also clear (from the following excerpt from Don's post) that
whatever language was called DoD-1 was first published in 1901.  I'd
be really curious what kind of computer language would have been
invented by DOD back then, when there were no computers and, I think,
no DOD.

                                -- Adam

 >
 >Don Nelson <nelson_don@tandem.com> wrote:
 >
 [snipped]
 >> It was published in June of 1961 (and cost the amazing sum of $1.25 - you 
 >> could purchase about three quarts of beer at my local saloon for that 
 >> in 1961).  It came to be called DOD-61. . . .

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <4um1l9$klq@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> jsa@alexandria (Jon S Anthony) wrote:
> >In article <4uj42h$j06@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <
> >> Realize it's much easier get a C compiler up and running for an embedded
> >> system that it is an Ada compiler. To even call it an Ada compiler it 
> >> must pass a validation suite. 
> >
> >First point: Why do you think this?  There seems to be quite a lot of
> >evidence indicating that this is not true.
> >
> >Second point.  Just plain wrong.  If you want, you can call your C++
> >compiler an Ada compiler.  Of course, no one will take you seriously,
> >but you are free to do so.
> 
> Well I'm not an Ada expert, but I have "Ada as a Second Language"
> by Norman Cohen and "Ada Programmer Handbook" by Dean Gonzalez.

You don't have to be an Ada expert, just someone with a clue.  That book
is out of date in general (Ada83) and in any event the so called registered
trademark bit was removed a good 7 or 8 _years_ ago.  It never held any
legal weight anyway.


> If I were to bid on a contract, tell the DOD I'm developing in Ada
> and submit C++, I think they would call that "fraud". 

This is just completely irrelvant to the point.  A compiler vendor can
call his product Ada if he wants, even if it does not comform in any
way with ISO/IEC 8652:1995.  Your bidding on the _use_ of Ada in a
project while using C++ is a completely different issue.


> I think part of the resistance to Ada is C belongs to the world.
> Ada belongs to the government! :-)
> 
> If this has changed, please enlighten me!

It was never like this, so you have always been in the dark.  However,
in the past, the cost of getting into it was really prohibitive except
for major players.  Now, with Gnu Ada (GNAT), an excellent high
quality system _freely_ available on all major platforms (UNI*, soon
to be VMS, Windoze(95/NT), DOS, and now MAC), this too is really _old_
think.  And the vendors are putting out the same or better excellent
implementations with full IDEs, built in GUI builders, etc., for
reasonable prices (in the MSVC++ range or less) for Windoze(95/NT) and
UNI*.

And, what's more, you can use your Ada code as Java applications.  The
Intermetrics AdaMagic Ada95 to Java compiler fully integrates with
Java (the JVM and the Java classes and Java applets).

Please consider this an attempt at your enlightenment :-)


For those who would like to browse a multi award winning web site for
further enlightenment, check out the Home of the Brave Ada Programmers:

http://lglwww.epfl.ch/Ada/

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <4unvt6$rq8@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> "James A. Squire" <m193884@csehp3.mdc.com> wrote:
> >Craig Franck wrote:
> 
> >> I think part of the resistance to Ada is C belongs to the world.
> >> Ada belongs to the government! :-)
> >
> >Yesterday's news.  Today this is no longer true, conceptually.
> >Implementation may take awhile yet, but the Ada language is going
> >commercial.  Count on it.
> 
> You are correct. When I made this statement, I used as a referece
> some old texts, that are clearly not up to date. Time to go to
> Barnes & Noble and buy something on Ada 95! Perhaps that way my
> comments will be more likely to correspond to the current state
> of the language. 


Coupla suggestions:

Barnes: Programming in Ada95
Cohen's _2nd_ Edition Ada as a Second Language (completely revamped for Ada95)

For some _really_ good stuff on concurrency and concurrency with OO,
Burns, Welling: Concurrency in Ada (Ada95 version).

Also, you can get hypertext/html versions of the Ada95 RM and Rationale at

http://lglwww.epfl.ch/Ada/

There you will also find Web based tutorials and a pretty good (largish)
paper on Ada for C/C++ programmers.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Norman H. Cohen]

In article <4um1l9$klq@mtinsc01-mgt.ops.worldnet.att.net>,
Craig Franck <clfranck@worldnet.att.net> writes: 

|> Well I'm not an Ada expert, but I have "Ada as a Second Language"
|> by Norman Cohen and "Ada Programmer Handbook" by Dean Gonzalez.
|> On the cover a little R with a circle around it appears by the
|> word Ada. In the book by Norman Cohen it states (page 8) that
|> the name "Ada" is a trade mark of the DOD and it's usage is
|> "strictly enforced".

As several people have pointed out, Craig is referring to the first
(1986) edition of "Ada as a Second Language".  The second (1996) edition
does not have a trademark symbol next to the word Ada and no reference is
made in the text to a trademark.  (In fact, I am not even sure the
trademark symbol appears on the cover of later printings of the first
edition.)

(Similarly, Bob Mathis's license plate no longer reads "ADA-TM".)

At the time the first edition of "Ada as a Second Language" went to
press, the Ada Joint Program Office truly believed that the trademark had
the force of law, and they fully intended to use the trademark to prevent
the proliferation of divergent dialects all called Ada.  They abandoned
the trademark shortly afterward upon being advised that it was
unenforceable.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <4v5pis$4h1@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> for C/C++ on Windows and UNIX platforms is the best of any language.
> Yes, you can program in Ada on a UNIX platform but I would point 
> out that the compiler is written in C.

Criminey.  By now, having made several such goof-ball errors of fact,
you would think that you would be just a little more careful before
blowing some more smoke and looking even more clueless than you've
already shown yourself to be.  The above statement is certainly not
true of any of the Ada compilers that I've used - on UN* or not.  The
one most people could use on UN* right now, GNAT (Gnu Ada) is written
in Ada95 (while reusing the standard GCC backend for code generation).

Is there any particular reason why you seem to like to parade your
ignorance in public like this?


> find myself falling victim to time and time again. Like when I'm
> writing : how many OSs or compilers are written in Ada? And not as
> an acedemic exercise to prove it is possible, but in actual use?

Compilers: A lot.  OSs: Boatloads.  You can legitimately argue that
virtually all embedded systems have OSs as part of their definition
and function.


> Well alot of the code for the telephone switching system is written 
> in C/C++. The system did become unstable do to (how ironic!) a poorly coded
> switch statement back in 1990, but on the whole I don't think there

How would you know?  My guess is that the things have several backups
in case of failures (software or hardware).


> I were to ride on the space shuttle, I would be concerned with how
> well the software was written and tested, not what language it

Sure.  And?  If there is any point here it concerns whether the
language helps in these regards.  There's a whole spectrum here from
actively helpful to passively benign to actively pernicious.  May as
well use the actively helpful.


> Well see above, and call AT&T and tell them that that they better get 
> started writing everything in Ada right away! :-) 

AT&T is irrelevant.  For several reasons.  Not the least of which is
that they have more old dog inertia than is humanly comprehensible.


> maintain when justifing language aspects. When the ANSI standard was
> submitted for public review, I believe the strongest objection was
> that the language was *huge*, and this was before OO extension were
> added.

Yes, this is another "software urban legend".  I suppose the fact that
the C++ draft is significantly bigger than ISO 8652:1995 eludes you.
This despite the fact that the Ada standard supports easy expression
of anything C++ does (often much simpler) and many things that C++
does not support, including full support for concurrent programming
and out of the box interoperation with other languages.


> It is important to have a historical perspective on things.

Yes.  Unfortunately, you continue to show that you do not have a clue
about the current situation let alone the historical one.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Craig Franck]

jsa@alexandria (Jon S Anthony) wrote:
>In article <4v5pis$4h1@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:
>
>> for C/C++ on Windows and UNIX platforms is the best of any language.
>> Yes, you can program in Ada on a UNIX platform but I would point 
>> out that the compiler is written in C.
>
>Criminey.  By now, having made several such goof-ball errors of fact,
>you would think that you would be just a little more careful before
>blowing some more smoke and looking even more clueless than you've
>already shown yourself to be.  The above statement is certainly not
>true of any of the Ada compilers that I've used - on UN* or not.  The
>one most people could use on UN* right now, GNAT (Gnu Ada) is written
>in Ada95 (while reusing the standard GCC backend for code generation).
>
>Is there any particular reason why you seem to like to parade your
>ignorance in public like this?

Ok, fine. I also have a C compiler written in C, a Pascal compiler
written in Pascal, and a BASIC compiler written in GEE WIZ BASIC. 
So yes, I imagine, if someone where to write an Ada compiler they would
write it in Ada95. The idea of using portable C to write compilers 
and then port them to other platforms was a hoax.

I have a CD-ROM from Simtel with ports of GNU 1.81 & 1.83 (GNU NYU Ada9x)
to Solaris, SunOS, Linux, HP, OS/2, and MS-DOS. I was not aware
they were all written in Ada95, (some compilers on the disk are for Ada83;
they may be written in Ada83) and the standard GCC backend was used. 

>> find myself falling victim to time and time again. Like when I'm
>> writing : how many OSs or compilers are written in Ada? And not as
>> an acedemic exercise to prove it is possible, but in actual use?
>
>Compilers: A lot.  OSs: Boatloads.  You can legitimately argue that
>virtually all embedded systems have OSs as part of their definition
>and function.

Thank you for answering that question! If I were to be asked to 
with what language a compiler or OS would be best written I would
say C/C++. That is just my opinion.

>> Well alot of the code for the telephone switching system is written 
>> in C/C++. The system did become unstable do to (how ironic!) a poorly coded
>> switch statement back in 1990, but on the whole I don't think there
>
>How would you know?  My guess is that the things have several backups
>in case of failures (software or hardware).

I know from talking to people, and reading books. A recent popular
book discused the notion of the C switch statement as a language defect
and pointed to the long distance phone service for AT&T becoming unstable. 
Some psudo-code was given. Yes, things like 911 service have so much
fault tolerance built in to the system that chance of falure is slim. 

>> I were to ride on the space shuttle, I would be concerned with how
>> well the software was written and tested, not what language it
>
>Sure.  And?  If there is any point here it concerns whether the
>language helps in these regards.  There's a whole spectrum here from
>actively helpful to passively benign to actively pernicious.  May as
>well use the actively helpful.

The point I was tring to make is you can write bad code in any 
language. Good programmers and software support are as important
as the language. Puting training wheels on a language by being 
able to write : FOR I IN Data 'RANGE LOOP
                  Put(Data(I), 3);
                END LOOP;
because programmers can't count, may be helpfull.


>> Well see above, and call AT&T and tell them that that they better get 
>> started writing everything in Ada right away! :-) 
>
>AT&T is irrelevant.  For several reasons.  Not the least of which is
>that they have more old dog inertia than is humanly comprehensible.

AT&T is perhaps irrelevant to you. But for some people Ada 
is irrelevant. Perhaps it is from irrelevancy that ignorance 
springs.

>> maintain when justifing language aspects. When the ANSI standard was
>> submitted for public review, I believe the strongest objection was
>> that the language was *huge*, and this was before OO extension were
>> added.
>
>Yes, this is another "software urban legend".  I suppose the fact that
>the C++ draft is significantly bigger than ISO 8652:1995 eludes you.
>This despite the fact that the Ada standard supports easy expression
>of anything C++ does (often much simpler) and many things that C++
>does not support, including full support for concurrent programming
>and out of the box interoperation with other languages.

I feel that as a language becomes larger and larger, learning
and implementing that language becomes more and more difficult.
But maybe its just a legend amoung C programmers that Ada is 
big. Someone once told me that the only good thing you could
say about Ada was in it there was a good little language struggling 
to get out. But he must have not had a clue either. Maybe my 
problem is the people I hang out with...

>> It is important to have a historical perspective on things.
>
>Yes.  Unfortunately, you continue to show that you do not have a clue
>about the current situation let alone the historical one.

Well, how well someone is "clued in" on something is a relative 
thing. I feel I know more about Ada now then when I started posting
on this thread. If you view this learning process as "ignorance on
parade" that is fine with me!

Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <4vb399$kt8@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

> >> Well alot of the code for the telephone switching system is written 
> >> in C/C++. The system did become unstable do to (how ironic!) a poorly coded
> >> switch statement back in 1990, but on the whole I don't think there
> >
> >How would you know?  My guess is that the things have several backups
> >in case of failures (software or hardware).
> 
> I know from talking to people, and reading books. A recent popular

Actually, I was refering to the bit (which I screwed up quoting) that
crashes and reboots don't often happen.  Again, this isn't something
you would typically hear about if backups picked up when the primaries
crapped out.


> book discused the notion of the C switch statement as a language defect
> and pointed to the long distance phone service for AT&T becoming unstable. 

Yes, of course, this is a well known case and the C switch statement is
clearly and widely acknowledged to be defective.

[[Historical Aside: Somewhere I think I saw something to the effect
that the C switch statement was a kind of artifact from RATFOR
(another K&R wonder) which used C like syntax but compiled to Fortran.
The story goes that the switch was compiled to computed gotos and used
the "break" as an easy hint to insert the goto to the "drop through
point".  Now, I know that C's immediate predecessors/heritage were B
and BCPL.  (I also know that the original "Software Tools" book was
written using RATFOR.)  So, does anyone know if this is utter rubbish
or has a grain of truth?]]


> >actively helpful to passively benign to actively pernicious.  May as
> >well use the actively helpful.
> 
> The point I was tring to make is you can write bad code in any 
> language. Good programmers and software support are as important
> as the language.

Anyone with a clue knows this and obviously would agree.  This is old
news.  The simple point is that if you have something that helps, why
not use it????

>Puting training wheels on a language by being 
> able to write : FOR I IN Data 'RANGE LOOP
>                   Put(Data(I), 3);
>                 END LOOP;
> because programmers can't count, may be helpfull.

Well, this is not a particularly good example, but it does show that A)
you don't get it and B) that it does help prevent _maintenance_ problems.

The Data'Range construct has nothing to do with being able to count or
not.  It ensures that the loop will work no matter _what_ the bounds
are.  You can change them all you want and the loop will still have
the proper termination condition with no changes.  You can even change
the index type to some enumeration (where counting is just plain
irrelevant).  No problem.  In fact, the bounds can be dynamically
determined and the loop will still work just fine.  In short, this is
a very simple example of _abstraction_ support in the language: No
matter _what_ the bounds are, the loop should process the whole array
and the programmer should not be messing around with the details of
such bounds because they are irrelevant.


> >AT&T is irrelevant.  For several reasons.  Not the least of which is
> >that they have more old dog inertia than is humanly comprehensible.
> 
> AT&T is perhaps irrelevant to you. But for some people Ada 
> is irrelevant. Perhaps it is from irrelevancy that ignorance 
> springs.

Absolutely true.  On all points.


> I feel that as a language becomes larger and larger, learning
> and implementing that language becomes more and more difficult.

First part (learning): False.  If the language is well designed and
orthogonal in its constructs and minimizes feature interaction this is
not true.  For example, learning the "Pascal" or "C" equivalent part
of Ada is as easy (and probably easier because of more consistent
syntax) than learning either Pascal or C.

Second part (implementing): True.


> But maybe its just a legend amoung C programmers that Ada is 
> big.

Well, compared to C, Ada _is_ big.  It has a _lot_ of support that C
just passes over and punts to the implementor or leaves up the
particular implementation.  Compared to Basic, C's big.  Compared to
Prolog C's enormous.  Shrug.


> Well, how well someone is "clued in" on something is a relative 
> thing. I feel I know more about Ada now then when I started posting
> on this thread. If you view this learning process as "ignorance on
> parade" that is fine with me!

I have no issue with "learning" at all.  I have no issue with any of
this really, I just don't understand why the process has to be one of:

a) various false statements asserted as though true
b) Falsity of such statements  pointed out.
a') more false statements asserted as though true.
b') more correction
a'')...
b'')...
...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Craig Franck]

jsa@alexandria (Jon S Anthony) wrote:
>In article <4vb399$kt8@mtinsc01-mgt.ops.worldnet.att.net> Craig Franck <clfranck@worldnet.att.net> writes:

>> Well, how well someone is "clued in" on something is a relative 
>> thing. I feel I know more about Ada now then when I started posting
>> on this thread. If you view this learning process as "ignorance on
>> parade" that is fine with me!
>
>I have no issue with "learning" at all.  I have no issue with any of
>this really, I just don't understand why the process has to be one of:
>
>a) various false statements asserted as though true
>b) Falsity of such statements  pointed out.
>a') more false statements asserted as though true.
>b') more correction
>a'')...
>b'')...
>...

It's true that this method of learning can be slow and frustrating
for both parties! My Simtel Ada CDROM has 1.1 GB of Ada documentation,
information and source code. I shall consult it more often before
responding to posts so as to have some basis for my statements. :-)

Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[Valentin Bonnard]

Jon S Anthony wrote:
> 
> I have no issue with "learning" at all.  I have no issue with any of
> this really, I just don't understand why the process has to be one of:
> 
> a) various false statements asserted as though true
> b) Falsity of such statements  pointed out.
> a') more false statements asserted as though true.
> b') more correction
> a'')...
> b'')...
> ...

That's the USENET normal process, I think...

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)










.

Re: C is 'better' than Ada because...

[Walter B. Hollman Sr.]

On Jul 04, 1996 16:16:39 in article <Re: C is 'better' than Ada
because...>, 'ian@rsd.bel.alcatel.be (Ian Ward)' wrote: 
 
 
>In article 57288085@netline-fddi.jpl.nasa.gov, kdq@emoryi.jpl.nasa.gov
(Kevin  
>D. Quitt) writes: 
>>On 30 Jun 1996 06:33:29 GMT, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)  
>wrote: 
>>>If you were shaving *my* face, I'd rather you not use a razor! 
>> 
>>How many barbers use an electric shaver on their customers? 
>> 
>>--  
>>#include <standard_disclaimer.h>                
http://emoryi.jpl.nasa.gov/ 
>> _ 
>>Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made
up 
>>Per the FCA, this email address may not be added to any commercial mail
list 
> 
>Not very many, but most use electric shears. 
>In fact, as a coincidence I shave with a cut throat 
>razor, made by Solingen of Germany. I do this, like 
>all things, because it meets my requirements, it gives 
>the best shave I think, when I have time to use it, 
>and it is cheap (very.) Ok, to be fair here, it cost 
>forty quid to buy new, and fifteen quid to buy the 
>leather strap. It now though, has extremely low 
>maintenance costs, and no waste.  
> 
>The right tool for the right job, and as such I 
>recognise that it has faults though, so conversely, 
>rarely, but when I am in a rush for a meeting 
>say, I use a Remington microscreen or twin blade Boots 
>throwaway, because, even though it is not as close as 
>a blade (despite the advertisements,) it is is close 
>enough, and I look less stupid with a bit of a five 
>o'clock shadow in the evening, than I would with a 
>huge hole in my face, due to a rushed shave. Jan Wuyts 
>will confirm this, he having seen me with one or two 
>disastrous cuts, because I may sneeze, or even just 
>took the thing for granted and stopped concentrating. 
> 
>Best regards, Kevin, but I bet you wear a seat belt 
>when you drive a car.  
> 
>--- 
>Ian Ward's opinions only : ian@rsd.bel.alcatel.be 
--If you believe 'C' is better than use it! 
Walter B. Hollman Sr 
 
 
 
 
 
 
 

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <Pine.SUN.3.91.960705092616.22981B-100000@erlang.praxis.co.uk> Peter Amey <pna@erlang.praxis.co.uk> writes:

> All this talk about skilled programmers and being over-protected by Ada 
> reminds me of something that was drummed into me during my aviating 
> days.  I was taught:
> 
> "The superior pilot uses his superior judgement to avoid situations that 
> would require his superior skill"
> 
> I use Ada precisely because it avoids the need constantly to demonstrate
> my superior skill :-)

Being an aviator myself, I think this is a good analogy and have used
it myself on occasion. Note that this applies even though (actually
_especially_) I fly aerobatics! ;-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Peter Hermann]

Jon S Anthony (jsa@organon.com) wrote:
: In article <Pine.SUN.3.91.960705092616.22981B-100000@erlang.praxis.co.uk> Peter Amey <pna@erlang.praxis.co.uk> writes:
: > I use Ada precisely because it avoids the need constantly to demonstrate
: > my superior skill :-)

: Being an aviator myself, I think this is a good analogy and have used
: it myself on occasion. Note that this applies even though (actually
: _especially_) I fly aerobatics! ;-)

me too. I am curious how many more in CLA fly (and especially aerobatics)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: C is 'better' than Ada because...

[Dirk Dickmanns]

ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) writes:

>Jon S Anthony (jsa@organon.com) wrote:
>: In article <Pine.SUN.3.91.960705092616.22981B-100000@erlang.praxis.co.uk> Peter Amey <pna@erlang.praxis.co.uk> writes:
>: > I use Ada precisely because it avoids the need constantly to demonstrate
>: > my superior skill :-)

>: Being an aviator myself, I think this is a good analogy and have used
>: it myself on occasion. Note that this applies even though (actually
>: _especially_) I fly aerobatics! ;-)

>me too. I am curious how many more in CLA fly (and especially aerobatics)

Hi Peter,

Just to have it said -- I am an "Ada" hangglider pilot doing more
and more aerobatics. The Wills Wing RamAir 154 is really great, also
for cross country flights. I won't want it programmed in C ;-)

I agree fully with Peter Amey and Jon S Anthony and also share
Robert Dewars comment on what they said.

Anyway, neither my flying nor my programming skills are in any
way (extremely :-) superior.

Sorry, off topic, off group, I should leave to
rec.aviation.hang-gliding...

Dirk

--
Dirk Dickmanns -- REALIS -- real-time dynamic computer vision
Sun OS 4.1.3; PC Linux; Ada, OCCAM, C, Eiffel, PROLOG, C++

Re: C is 'better' than Ada because...

[ntxbow]

In article <dewar.836839308@schonberg>, Robert Dewar <dewar@cs.nyu.edu>
writes
>Kevin says
>
>"I do the same in C.  The problem is that Ada won't *let* you use your superior
>skill, i.e., nothing is gained by it.  For someone who knows what they're
>doing, it's just as easy to write good, clean, safe code in C (or assembly, or
>*any* language) as it is in Ada."
>
>
>
Sorry, but you're spouting rubbish, I've worked on several large
projects, some safety critical some not, some Ada some C, some mixed,
all staffed by various levels of software engineer, coder, hacker,
whatever.  I would not wish to fly on an aircraft with its safety
critical aspects looked after by a C program, there are too many
variables (no pun intended), the varying people who work on projects
chuck out varying quality of code, using your "superior skill" in my
book would mean using junk code that I would bounce as it would be
difficult to maintain and probably risky in implementation.  It's horses
for courses, if you want a GUI on a PC running word, use C, if you want
a system that's going to look after peoples lives or whatever use Ada,
if you believe otherwise carry on ranting but we who have to implement
these systems will just laugh at your naivety and avoid being sued for
implementing a system that spoiled someones day big time.  Rant ends ;-)

jeff farr

-- 
ntxbow

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On Fri, 12 Jul 1996 09:29:10 +0100, ntxbow <ntxbow@ntxbow.demon.co.uk> wrote:
>using your "superior skill" in my
>book would mean using junk code that I would bounce as it would be
>difficult to maintain and probably risky in implementation.

I'd bounce any code like that myself.  My code is clean, simple, well
documented, and as portable as hardware demands allow.  Complex code running
with simple data will always be problematic; simple code with sophisticated
data can easily accomplish the same things and can be simple to fully test.

I don't consider obfuscated code to be superior in any sense; if it's really
that time-critical that the compiler doesn't do the job from normal code, I'll
use assembler and guarantee it's right.

And my rant here is against the arrogance of those of you who consider
"superior skill" in C to be hack code.  I am forced to wonder about those who
disdain programming skill - in favor of what?

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Robert Dewar]

iKevin says

  My code is clean, simple, well
  documented, and as portable as hardware demands allow.

And later:

  And my rant here is against the arrogance of those of you who consider
  "superior skill" in C to be hack code.

Quite right, we certainly don't want any arrogance on this newsgroup do we :-)

Re: C is 'better' than Ada because...

[Ian Ward]

In article 247859913@netline-fddi.jpl.nasa.gov, kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes:
>On Fri, 12 Jul 1996 09:29:10 +0100, ntxbow <ntxbow@ntxbow.demon.co.uk> wrote:

... huge snip ...

Whilst, as a result of the infantile quality of arguments you field for
your case, I believe not a single word you have posted. However, my
ambition to write ever more reliable software demands that I ask you
how you do it. I am just too curious, I guess.
(Just in case you 'actually can' write totally reliable software, and
are not some kind of enormous bullshitting troll.)

Perhaps you can outline your techniques, and analysis, design, coding and
testing methods, and what sort of coding speeds you get on various size
projects (from say, a 10K Sloc application to say a typical, million line
project,) that I might go home and read them. I would enjoy a rest from
Date's Guide to Ingres, Stroustrop's C++ programming language, and Vol
10 of Club International for a couple of nights.

Best regards,
Ian

Ian Ward's opinions only : ian@rsd.bel.alcatel.be
Note there are no smileys, I actually do want to know how you do it.

Re: C is 'better' than Ada because...

[Dale Stanbrough]

Mark A Biggar writes:
"In addition the above code make it almost impossible to optimize
 out unnecessary checks.  The empirical evidence is that only about
 10% of array bounds checks are really necessary, assuming that you
 can declare index variables that are limited in range to the 
 array bounds, but you can't so that either in C (you can in C++,
 but that adds yet another layer of possible redundant checks
 that you can't easily optimize away.)"


By special casing the array template, and providing a suitable iterator,
couldn't a clever compiler optimize away most checks anyway?

Dale

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <31f3c396.238311543@netline-fddi.jpl.nasa.gov> kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes:

> >>Essentially, yes.  I prefer an environment that doesn't make it easy
> >for code >to work by accident.
>
> >AHA! Exactly what Ada gives you and C does NOT!.
>
> An environment, not a language.  The tools available do a sufficient job for
> me.

A language is part of an "environment", so this is irrelevant.


> Let me back off one thing, though.  I don't mean to say that C is "superior"
> to ADA; I'd have to be an expert at both, not just one to actually have an
> opinion.  What I mean is that I like C, and I don't like ADA; so for me, C is
> "better".

OK, whatever floats your boat.


> (BTW, I just wrote the embedded code for the Telemetry Control Unit on the
> Cassini Spacecraft, in C of course, in well under 8K or ROM.  Is it possible
> to generate a stand-alone ADA program that will run in that space?)

Of course.  Why would you think otherwise?


> I'll further point out that on the Cassini craft, from all I've heard, the
> software developed in ADA is behind schedule and functionally deficient.

Yes, and third hand anecdotal evidence isn't saying much of anything.
Actually, even "good" anecdotal evidence is a problem.  One of the
only real objective sorts of studies on this type of thing (language
comparisons and results) was done by Rational (comparing C and
Ada(83)).  It can be read at

/sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html

This is quite a good piece of work and should be read by anyone
interested in this sort of issue, and certainly by anyone taking a
"stand" on them.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[William Clodius]

In article <01bb7bf9$b89a1740$96ee6fcf@timhome2> "Tim Behrendsen"
<tim@airshields.com> writes: 

   Theodore E. Dennison <dennison@escmail.orl.mmc.com> wrote in article
   <31F613F3.2781E494@escmail.orl.mmc.com>...
   > Tim Behrendsen wrote:
   > > 
<snip>
   > 
   > You have a good point. Unfortunately, your premise is wrong. Ada is in 
   > extensive use outside of the Government. In fact it is the language of 
   > choice wherever a software failure is liable to cause loss of life or a 
   > very large lawsuit. 

<snip>
   Based on your post, Ada is only appropriate for mission critical
                              ^^^^
   applications, and not for other applications? Again, the question,
                     ^^^
   and I ask this respectfully, "If it's so good, why isn't it used more
   universally than it is?"  And, if C is so bad (in many people's opinion,
   not mine), why is it used almost universally, despite its acknowledged,
   real problems?

First, Dennison's post indicates that Ada is believed to be the most
appropriate language for mission critical applications. That by itself
says nothing whatsoever about its applicability, or lack thereof, for
other applications.

Second, several people in this thread have already addressed your
question about why is C used far more often than Ada. The answer has
typically been that this difference in useage is almost entirely due
to social and historical factors, beyond the relative merits of the
languages. You may or may not believe this explanation, but if you
are truly respectful of those that have responded to your question you
would at least recognize that they have given an answer. Ideally you
would also note why you do, or do not, believe that their answer is
valid.

Third, while the intrinsic merits of a language are important, those
merits may differ in importance from problem to problem, and must
include such social and historical factors as: are there lots of
programmers available that are trained in this language; how easy is
it to interface to the operating system in this language; how
expensive are compilers for the language; are there non-compiler tools
available for the language that compensate for the language's
weaknesses; how much control do I want over the details of
implementing a given algorithm (Ada and C are very comparable on this
point); are compilers available for all platforms of interest (the is
portability practical question); etc. Most of the above
(specification of the algorithm independent of system is an
exception), are very much history or culture dependent:

1. It takes time to train students and there is a tendency to train
them in the most popular language.

2.  It takes time for an OS to be written and it is very expensive to
replace it.

3. A large part of the price of a compiler is determined by cumulative
sales volume. An old and popular language has less expensive compilers
than a new language.

4. An older popular language will have more tools available than a
newer language.

5. Many programmers will avoid pure functional languages, because of
their lack of control over the implementation of an algorithm,
although their semantics allows a compiler to generate more optimal
code. 

6. New languages take time to have wide availability.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545

Re: C is 'better' than Ada because...

[Darin Johnson]

> > Do you suppose it would take the world by storm?
> > Well, _I_ use it, but no, Clean (for that is its name), has _not_ taken
> > the world by storm, and I don't expect it will.
> 
> Never know; maybe you should write a free operating system in it. :)

Some people are going to use the language anyway, there are language
junkies out there.  Most people though, won't give it a second glance
until it becomes popular, a tough catch-22.  They certainly don't want
to suddenly have the language vanish and get stuck with a program
that's painful to maintain (I've heard a horror story about a commonly
used admin utility written in Icon, and then the programmer left and
no one can maintain it but it's still in use; Icon is a nice language
but if no one knows it...).  Here's some important things to do to
give your new fictitious language a boost:

Make it free.  Make it portable.  This lets it get on multiple
systems, so that you don't get users trapped (if it only ran on UNIX,
you'd never get Windows users, and vice versa).  Being free, users can
modify it and make suggestions, and port it for you for free.  Forget
the money, people aren't going to spend a lot of money even on proven
languages.  Eiffel is a wonderful language from what I've seen, but I
don't want to buy it and I've never seen a system where it was
installed.

Have it generate C code as the backend.  Don't bother with native code
generation until it's caught on.  This makes your language much more
portable, and you can leverage off of the large C community and C
optimizers.  If you really want native generation, at least allow the
C code as an option (thus, you don't become obsolete when the customer
moves to a different machine, and the customer's code can still be
used).

Make sure your giant runtime system is justified.  If you can't easily
build standalone applications, you chop out a big chunk of the market.
Your customers shouldn't have to require that their customers have
your runtime system.

Don't fall in love with your language.  Be prepared to take criticism,
and to actually make use of it.  Be prepared to abandon your
principles.  Your customers won't care at all that you upheld your
principles, but they will care that won't make a change they consider
vital.

In short, figure out why existing languages got popular before they
had critical mass, and try to use the same concepts when you can.
-- 
Darin Johnson
djohnson@ucsd.edu	O-
       Support your right to own gnus.

Re: C is 'better' than Ada because...

[Tim Behrendsen]

Darin Johnson <djohnson@tartarus.ucsd.edu> wrote in article
<qqk9vkawin.fsf@tartarus.ucsd.edu>...
> > > Do you suppose it would take the world by storm?
> > > Well, _I_ use it, but no, Clean (for that is its name), has _not_
taken
> > > the world by storm, and I don't expect it will.
> > 
> > Never know; maybe you should write a free operating system in it. :)
> 
> Some people are going to use the language anyway, there are language
> junkies out there.  Most people though, won't give it a second glance
> until it becomes popular, a tough catch-22.  They certainly don't want
> to suddenly have the language vanish and get stuck with a program
> that's painful to maintain (I've heard a horror story about a commonly
> used admin utility written in Icon, and then the programmer left and
> no one can maintain it but it's still in use; Icon is a nice language
> but if no one knows it...).  Here's some important things to do to
> give your new fictitious language a boost:
>
> [PARAPHRASE: Make it free; make it portable; generate C as backend;]
> [Moderate runtime requirements; take criticism]

Very interesting; I quite agree.  I would only add... make it
possible to coexist with another language, such as C. We use TCL
here as a simple scripting language that we were able to drop into
our application for site customization purposes.  If it was "all TCL
or nothing", I never would have used it.

This is not a pure example, since TCL is an interpreted shell
language, but my point is that if you make it easy for people to
have a middle ground to experiment with a language to see what
benefits can be made, a new language has a much better chance of
succeeding.

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <qqk9vkawin.fsf@tartarus.ucsd.edu> djohnson@tartarus.ucsd.edu (Darin Johnson) writes:

> but if no one knows it...).  Here's some important things to do to
> give your new fictitious language a boost:
> 
> Make it free.  Make it portable.  This lets it get on multiple
> systems, so that you don't get users trapped (if it only ran on UNIX,
> you'd never get Windows users, and vice versa).  Being free, users can
> modify it and make suggestions, and port it for you for free.  Forget

Fortunately, this time around Ada (Ada95) takes this sort of approach.
GNAT (Gnu Ada) was/is the pump primer and an excellent compiler in its
own right.  It has been ported all over the place.

> Have it generate C code as the backend.  Don't bother with native code
> generation until it's caught on.  This makes your language much more

Better yet: take advantage of existing code generators and generate
the IL they expect.  This is what GNAT did (it uses the GCC backend -
it does NOT generate C code) by targetting a code generator that is
itself targetted to many platforms.  The Intermetrics AdaMagic
frontend flips this around and is designed to accomodate many
different flavors of backends.  Generating C code is clumsy, cannot
take advantage of as much optimization potential, and makes debugging
a nightmare.

> Make sure your giant runtime system is justified.  If you can't easily
> build standalone applications, you chop out a big chunk of the market.

Standalone applications are never a problem.  It's when your RTS might
interact in adverse ways with other aspects of a more complex
environment that you can get into trouble.  Fortunately, people have
worked hard so that this is not a problem with the new Ada
implementations.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <31fff06f.186046460@netline-fddi.jpl.nasa.gov> kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt) writes:

> On 31 Jul 96 10:36:37 GMT, dirk@hera.informatik.unibw-muenchen.de (Dirk
> Dickmanns) wrote:
> 
> >What made me looking at Ada was
> >the extreme commitment to Ada of people using C before... think about
> >it.
> 
> Curious.  It's that's same commitment to C from former Ada programmers that
> makes me so leery of Ada.  Especially since these are all people whom I
> consider to be good programmers (not a distinction I give lightly).

Just goes to show that anecdotal evidence is typically not a very good
guide.  Again, about the only real hard objective investigation into
this issue (language comparison) was done by Verdix/Rational over a
several year time frame comparing Ada and C as used on many different
projects by highly qualified people.  They aquired a lot of data
and did a good job of analysis.  Anyone who wants at least _some_
"hard" data on this issue should read that report:

http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Stefan 'Stetson' Skoglund]

It exists a number of reasons why peopler leaves it work for something
another. Maybe a bad boss, awful offices, being mistreated by colleagues
on the project... and so on.

It isn't fun being on the lowest pin of an office's pecking ladder.

Look on the recent Astra debacle in the US. Things such as that
isn't that unusual.

Do you remember that scandal about sex-abuse on a Las Vegas hotel
there male NAVY officers penalized female officers while on
an conference !

-- 
---------------------------------------------------------------------
Stefan 'Stetson' Skoglund          I               |
sp2stes1@ida.his.se                I               |
<http://www.his.se/ida/~sp2stes1/> I         _____/0\_____
                                   I ____________O(.)O___________
H\"ogskolan i Sk\"ovde, Sverige    I      I-+-I    O    I-+-I
                                   I
                                   I      Viggen with two Rb04
---------------------------------------------------------------------

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <3212F127.41C67EA6@mailgw.sanders.lockheed.com> Mike Roske <mroske@mailgw.sanders.lockheed.com> writes:

> However, the language does not readily provide for some constructs I
> have found very useful, such as pointers to subprograms, and assigning a
> pointer to an existing object.  (yes, both can be done, but not as
> easily as in C).

Yes, this is cake in Ada95, but not something you typically want anyway
(especially since you have polymorphic dispatch).


> The added checking that Ada compilers provide before and after each
> subprogram call and assignment is unnecessary in many cases.

I don't think I know of an Ada compiler (even some of the worst old Ada83
ones) that didn't allow globally supressing checks at invocation.  And
certainly, there was always pragma supress.  So this is irrelevant.  Don't
want the checks?  Well, turn them off.


> Admittedly, this is more of an implementation issue.  There must be some
> Ada compilers that optimize well, but I haven't yet had the pleasure
> of using them.

Sure, they are out there.  Some do much better than any C compiler in
their target areas.  This is all well known stuff and old news...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[James A. Squire]

Kevin D. Quitt wrote:
>
> C is better than Ada, because it doesn't pretend it knows more about
> programming than I do, and doesn't prevent me from doing those things that are
> upon rare occasion necessary.  Programming is C is like shaving with a razor;
> as long as I know what I'm doing, there's no problem.   Programming in Ada is
> like using a shaver; it 'protects' the incompetent and is no help to the
> experts.

Ah yes, the libertarian-utopian approach to programming.  Speaking as
one who shaves with an electric shaver, you can call me incompetent if
you like, but I rest easy knowing I will never draw blood from my neck.
Furthermore, I know many software engineers who "know what they are
doing" (yours truly included) and who are ready at the drop of the hat
to ignore that knowledge in order to cut any corner they can to get the
job done on deadline (or so we perceive).  Programming is a science; its
practitioners (including me) persist in treating it as an art form.  Do
we need restraints in a language that, by the by was designed by people
who DO very much "know more about programming than I do"?  Betcherass
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: C is 'better' than Ada because...

[Darin Johnson]

> Ok, then here's a challenge.  Point me at any compress/decompress
> package (a la Zip) written in Ada.  I've been searching the world and
> come up empty.  Even here in the comp.lang.ada group I was referred to C
> language implementations.

This just means you can't find an existing one, not that it's
impossible.  Have you tried writing it yourself?  If you have problems
with it in Ada, I bet you also have problems with it in standard C
(ie, you can't tell how many bits are in a byte, or other binary
format details).
-- 
Darin Johnson
djohnson@ucsd.edu	O-
  - I'm not a well adjusted person, but I play one on the net.

If your only tool is a hammer, all your problems look like nails (was Re: C is 'better' than Ada because...)

[Bruce Clement]

In <qqloh2crie.fsf@tartarus.ucsd.edu> djohnson@tartarus.ucsd.edu (Darin Johnson) writes:
...
>This just means you can't find an existing one, not that it's
>impossible.  Have you tried writing it yourself?  If you have problems
>with it in Ada, I bet you also have problems with it in standard C
>(ie, you can't tell how many bits are in a byte, or other binary
>format details).

#include <stdio.h>
#include <limits.h>
int main(void) {
   printf("According to the preprocessor symbol CHAR_BIT " 
	  "defined in clause 5.2.4.2.1\nthere are %u \"bits "
	  "for smallest object that is not a bit-field (byte)\"\n",
	  (unsigned)CHAR_BIT);
   return 0;
}

--

Not speaking for my employers

-- 
Bruce Clement bruce@shell.co.nz

X.400:  c=NZ;a=SYNET;p=SHELL;o=SNZ_WELLINGTON;
        ou1=ICDI;ou2=MSMAIL;S=CLEMENT;g=BRUCE;i=BI
         

Re: C is 'better' than Ada because...

[Spasmo]

Tim Behrendsen (tim@airshields.com) wrote:
: system@niuhep.physics.niu.edu wrote in article
: <4tijip$rlo@corn.cso.niu.edu>...
: > Why are you so prejudiced against Ada?  You know next to nothing about it
: > But reading your original post you have essentially already decided what 
: > Ada is.

: [bringing out the fire extinguisher]
: I'm not; my questions/statements were in response to the points raised
: by the original author.  I know nothing about Ada; it's advocates seem
: to feel that is a very good language, however.  I'm curious why it
: hasn't caught on, when it has had so much time to gain a larger
: following that it has.  

Hello Tim, fancy seeing you here :).  Well I felt compelled to
jump in on this thread to respond to your point.  Firstly you
posted what you claimed were your credentials in the Quake newsgruop
and so it really surprises me that you would take the attitude
that greater popularity necessarily implies superiority.  I mean
the world is full of examples of things which are more popular
than others, but not necessarily better.  I know you like M$ so
I won't bring that up, but a wonderful point another person
brought up was MacDonald's (which I refer to as McDeath Burger).
Another good point would be to compare the number of Ford
Escorts on the road to Lamborghinis.  There are many more
Ford Escorts than Lamborghinis, but would you care to argue
that they are more numerous because they are superior?  I
hope you see the point.

I for one do think that not only is Ada a wonderful language,
but in many ways it surpassess C/C++, and this is coming from
a person who originally approached Ada with a condescending
attitude!  

When I first looked at Ada, I did coding in C/C++ and loved
them both (I still do).  I saw a superficial similarity
to Pascal, scoffed and walked away.  I kept this attitude
for a long time until one day I had nothing better to do
so for reading materials I read an ancient Ada83 book.
This sparked my interest so I researched the matter
futher, and do you know what?  I think the language is
beautiful, and far more intelligently designed than
C/C++.  I mean you've got power, wonderful support for
modular programming (far superior to C/C++), ease of
use, readability (something C/C++ have almost none of),
and safety!

In any case this long ramble was meant to illustrate that
I am one example of a person who was converted to Ada95
because I genuinely believed it to be a better choice than
C/C++.


However to put it in terms that a C/C++ programmer could
instantly identify with:

	popularity != superiority

Add about 3 levels of indirection and a few infix and
postfix incrementations and you're all set :)


: -- Tim Behrendsen (tim@airshields.com)

--
Spasmo
"Everyone has secrets, but sometimes you get caught,
 So if it's just between us, my silence can be bought"
	"Blackmail" by Sloppy Seconds

Re: C is 'better' than Ada because...

[Jon S Anthony]

In article <01bb7e29$61e3d260$87ee6fce@timpent.airshields.com> "Tim Behrendsen" <tim@airshields.com> writes:

> Unfortunately, it's difficult to discuss comparative language
> issues without needing to intersperse "This is not a bait!"
> between each sentence.  I started the thread admitting that
> I know nothing, and at least trying to assure people that I was

I think part of the problem here is that despite some of your comments
to the contrary, you really do seem set in your ways.  Old dog new trick
problems and all that.  So, it is not much use responding to most of what
you have to say.  Still, this one point:

> sincerely interested in discussing why C has become extremely
> popular, but Ada seems mired in more the "big iron" worlds.

is really odd.  I'm not sure there even is any Ada in the "big iron"
worlds.  That is the land of COBOL and more recently some success with
Smalltalk.  I have never used Ada on "big iron" and have used it on
and for several years.  In the last year or so, we have gone
completely over to use of Ada95 pretty much exclusively.  Our
platforms are various UNI* and Win* stuff.  It is worth noting that
the Ada95 on Win* is either free (GNAT with self extracting installer
and all) or cheap (ObjectAda from Tomson offering a full Win*
environment).

The problem here isn't so much that you don't have a clue (as you
admit) but rather that you don't appear to want one.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C is 'better' than Ada because...

[Tim Behrendsen]

Jon S Anthony <jsa@alexandria> wrote in article
<JSA.96Jul31152443@alexandria>...
> In article <01bb7e29$61e3d260$87ee6fce@timpent.airshields.com> "Tim
Behrendsen" <tim@airshields.com> writes:
> 
> > Unfortunately, it's difficult to discuss comparative language
> > issues without needing to intersperse "This is not a bait!"
> > between each sentence.  I started the thread admitting that
> > I know nothing, and at least trying to assure people that I was
> 
> I think part of the problem here is that despite some of your comments
> to the contrary, you really do seem set in your ways.  Old dog new trick
> problems and all that.  So, it is not much use responding to most of what
> you have to say.  Still, this one point:

I am a *very* conservative programmer.  I believe in the tried and
true, and letting *other* pioneers take the arrows.  It's the
people that follow the pioneers that build the cities.

> > sincerely interested in discussing why C has become extremely
> > popular, but Ada seems mired in more the "big iron" worlds.
> 
> is really odd.  I'm not sure there even is any Ada in the "big iron"
> worlds.  That is the land of COBOL and more recently some success with
> Smalltalk.  I have never used Ada on "big iron" and have used it on
> and for several years.  In the last year or so, we have gone
> completely over to use of Ada95 pretty much exclusively.  Our
> platforms are various UNI* and Win* stuff.  It is worth noting that
> the Ada95 on Win* is either free (GNAT with self extracting installer
> and all) or cheap (ObjectAda from Tomson offering a full Win*
> environment).
> 
> The problem here isn't so much that you don't have a clue (as you
> admit) but rather that you don't appear to want one.

The fact that I put my ignorance out for public display means I
am interested in gaining "a clue".

It's not just that I'm curious about Ada (which I am), but I'm also
curious why some languages become more popular than others.  I have
heard very few criticisms of Ada, which is quite remarkable.  Given
the rarity of criticism, it makes me wonder what keeps it out of the
mainstream, or at the very least, under the radar of popular
programming culture.

Re: C is 'better' than Ada because...

[Ralph Silverman]

Tim Behrendsen (tim@airshields.com) wrote:
: Jon S Anthony <jsa@alexandria> wrote in article
: <JSA.96Jul31152443@alexandria>...
: > In article <01bb7e29$61e3d260$87ee6fce@timpent.airshields.com> "Tim
: Behrendsen" <tim@airshields.com> writes:
: > 
: > > Unfortunately, it's difficult to discuss comparative language
: > > issues without needing to intersperse "This is not a bait!"
: > > between each sentence.  I started the thread admitting that
: > > I know nothing, and at least trying to assure people that I was
: > 
: > I think part of the problem here is that despite some of your comments
: > to the contrary, you really do seem set in your ways.  Old dog new trick
: > problems and all that.  So, it is not much use responding to most of what
: > you have to say.  Still, this one point:

: I am a *very* conservative programmer.  I believe in the tried and
: true, and letting *other* pioneers take the arrows.  It's the
: people that follow the pioneers that build the cities.

: > > sincerely interested in discussing why C has become extremely
: > > popular, but Ada seems mired in more the "big iron" worlds.
: > 
: > is really odd.  I'm not sure there even is any Ada in the "big iron"
: > worlds.  That is the land of COBOL and more recently some success with
: > Smalltalk.  I have never used Ada on "big iron" and have used it on
: > and for several years.  In the last year or so, we have gone
: > completely over to use of Ada95 pretty much exclusively.  Our
: > platforms are various UNI* and Win* stuff.  It is worth noting that
: > the Ada95 on Win* is either free (GNAT with self extracting installer
: > and all) or cheap (ObjectAda from Tomson offering a full Win*
: > environment).
: > 
: > The problem here isn't so much that you don't have a clue (as you
: > admit) but rather that you don't appear to want one.

: The fact that I put my ignorance out for public display means I
: am interested in gaining "a clue".

: It's not just that I'm curious about Ada (which I am), but I'm also
: curious why some languages become more popular than others.  I have
: heard very few criticisms of Ada, which is quite remarkable.  Given
: the rarity of criticism, it makes me wonder what keeps it out of the
: mainstream, or at the very least, under the radar of popular
: programming culture.

--
************begin r.s. response******************

	re.
	 "...what keeps it out of the mainstream..."
	 (ada).

	welcome to the real world...

	real programmers generally are employees
	tracked into work by school,  employer
	etc.

	the origins of ada are dod as indicated
	elsewhere on this thread...

	ask the pentagon!

************end r.s. response********************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: C is 'better' than Ada because...

[Bob Kitzberger]

I brought up the Mcdonald's comparison, and I'm afraid that the
analogy can only be taken so far.  In technology in particular, the
barrier to entry for new technologies is very high.  There is an
enourmous investment in C (just as there is in COBOL).  Ousting
C from (perhaps an imagined) first-place in the language wars
requires a fairly large state shift, and being one or two times
better is not enough.  You have to be an order of magnitude or more
better to overcome the inertia.  The DOS-->Windows transition
occured when there were far better platforms available (Amiga,
MacOS).  The state transition from DOS-->Windows required less
overall energy than a transition from, say DOS-->MacOS, and so
it happened.  Success begets success.  The transition from C-->C++
(if it occurs) will be because C++ offers improvements at _apparent_
low cost vs. a transition from C-->Ada.  

(I say "imagined" first place, because I continue to see statistics
that favor VBasic and/or COBOL over C, and it's not clear who to
believe...)

You can't look at market dominance from a technical standpoint
alone (your observance that McD's may really be in the child care
business is a kean observation: recent ad campaigns for McD's
target exactly that aspect).

IMHO.

--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

Re: C is 'better' than Ada because...

[Tim Behrendsen]

Bob Kitzberger <rlk@rational.com> wrote in article
<4tmqof$ivt@rational.rational.com>...
> [snip]
> better is not enough.  You have to be an order of magnitude or more
> better to overcome the inertia.  The DOS-->Windows transition
> occured when there were far better platforms available (Amiga,
> MacOS).  The state transition from DOS-->Windows required less
> overall energy than a transition from, say DOS-->MacOS, and so
> it happened.  Success begets success.  The transition from C-->C++
> (if it occurs) will be because C++ offers improvements at _apparent_
> low cost vs. a transition from C-->Ada.  

I agree, but there is precedent for large shifts in development
philosophy.  Mainframe --> PC.  Assembly O/S --> HLL O/S.
Proprietary S/W --> Portable S/W.  Fortran --> C.  Char --> GUI.

Now, based on what I've seen so far, we are talking about a
shift from "close to the metal" HLLs to "robust, protect people
from themselves, put in the investment up front" HLLs (correct me
if I wrong in my perception).

If that were the case, the question would be... is it worth it?

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[William Clodius]

In article <01bb7fd4$6a0f4300$87ee6fce@timpent.airshields.com> "Tim
Behrendsen" <tim@airshields.com> writes: 

<snip>

   I had an [ex-]employee who wrote the slowest code on the face of
   the earth.  Because of performance problems in our application,
   I went through and analyzed his code.  The man almost never used
   pointers, and almost always used array accesses.  These algorithms
   were much more complex that the trivial examples we've been
   talking about.

   I rewrote the subroutines to use pointers, and with an eye toward
   easy optimization by the compiler.  The algorithms used were
   exactly the same; I just reworked the stylistic expression of them.
   I didn't view the assembly language output, or anything processor
   specific like that.  I simply coded things in a straightforward
   data-flow sort of way, keeping the amount of context information
   that the compiler needed at any one point in the subroutine to
   a minimum.

   I was easily able to get 3-4x performance improvements.

<snip>

This anecdote by itself says nothing. It says that you had an employee
wrote slow code and that he used arrays. Unfortunately, because you
never determined the specific sources of the inefficiencies, it does
not say that the slow code was due to the use of arrays. It could very
well be due to the misuse of arrays, in particular if he used column
major order instead of C's preferred row major order, or due to
entirely different reasons. It is possible for a knowledgeable person
to write very efficient code using arrays.
-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545

Re: C is 'better' than Ada because...

[Tim Behrendsen]

William Clodius <clodius@hotspec.lanl.gov> wrote in article
<g1spa6hihy.fsf@hotspec.lanl.gov>...
> In article <01bb7fd4$6a0f4300$87ee6fce@timpent.airshields.com> "Tim
> Behrendsen" <tim@airshields.com> writes: 
> 
> <snip>
> 
>    I had an [ex-]employee who wrote the slowest code on the face of
>    the earth.  Because of performance problems in our application,
>    I went through and analyzed his code.  The man almost never used
>    pointers, and almost always used array accesses.  These algorithms
>    were much more complex that the trivial examples we've been
>    talking about.
> 
>    I rewrote the subroutines to use pointers, and with an eye toward
>    easy optimization by the compiler.  The algorithms used were
>    exactly the same; I just reworked the stylistic expression of them.
>    I didn't view the assembly language output, or anything processor
>    specific like that.  I simply coded things in a straightforward
>    data-flow sort of way, keeping the amount of context information
>    that the compiler needed at any one point in the subroutine to
>    a minimum.
> 
>    I was easily able to get 3-4x performance improvements.
> 
> <snip>
> [paraphrase: Anecdote about bad code with very complex array]
> [manipulations being 3-4x slower than code rewritten with pointers]
> 
> This anecdote by itself says nothing. It says that you had an employee
> wrote slow code and that he used arrays. Unfortunately, because you
> never determined the specific sources of the inefficiencies, it does
> not say that the slow code was due to the use of arrays. It could very
> well be due to the misuse of arrays, in particular if he used column
> major order instead of C's preferred row major order, or due to
> entirely different reasons. It is possible for a knowledgeable person
> to write very efficient code using arrays.

Well, you say my anecdote says nothing, then turn around and say that
it requires a "knowledgeable person" to do arrays correctly.  If modern
compilers are so good that programmers shouldn't have to worry
about using arrays, then it should have been smart to optimize
"misuse of arrays".

The point is, pointers are native to machine architectures, so it's
going to be easier for the optimizer to produce straightforward
optimizations if the programmer doesn't do anything dumb by
creating unsafe side effects.

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[Kevin D. Quitt]

On 3 Aug 1996 05:06:55 GMT, "Tim Behrendsen" <tim@airshields.com> wrote:

>William Clodius <clodius@hotspec.lanl.gov> wrote in article
><g1spa6hihy.fsf@hotspec.lanl.gov>...
>> In article <01bb7fd4$6a0f4300$87ee6fce@timpent.airshields.com> "Tim
>> Behrendsen" <tim@airshields.com> writes: 
>>    I had an [ex-]employee who wrote the slowest code on the face of
>>    the earth.

Not a chance.  One guy I knew wrote an I/O driver for an ASR-33 Teletype's
paper tape reader that slowed the reader down from 10 CPS to 7.5 CPS.  Very
impressive since there were no deliberate delay loops.

While reasonable C compilers on modern 32 machines emit the same code for
equivalent (simple) pointer and array indexing code, the fact is that the use
of pointers is one of the things that limits what an optimizer can do; that's
why you'll find "assume no aliasing" flags on most C compilers.  What's
happening to an array in a loop is usually pretty obvious; enough so that
compilers can make use of special indexing instructions, pipelining,
vectorization, and parallel execution.

When pointers are used, and you aren't guaranteed that aliasing can't happen,
you can't safely make the same assumptions you can about array indexing.  In
addition, some mainframes and supercomputers are tuned for array indexing and
are *much* better at it than at pointer deferencing.

-- 
#include <standard_disclaimer.h>
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list

Re: C is 'better' than Ada because...

[Stefan 'Stetson' Skoglund]

Hrmm, arrays in C is rather sensitive to column or row major mode
performance-vice because the compiler will not change the major mode
in a way contradicting against the programmers intentions.

To do something like optimizing major mode accesses in arrays
would require global optimizations.

The compiler can't optimize misuse of arrays in my view.

Pointers forces you to think on theese kinds.

-- 
---------------------------------------------------------------------
Stefan 'Stetson' Skoglund          I               |
sp2stes1@ida.his.se                I               |
<http://www.his.se/ida/~sp2stes1/> I         _____/0\_____
                                   I ____________O(.)O___________
H\"ogskolan i Sk\"ovde, Sverige    I      I-+-I    O    I-+-I
                                   I
                                   I      Viggen with two Rb04
---------------------------------------------------------------------

Re: C is 'better' than Ada because...

[William Clodius]

In article <01bb80f9$5df267c0$9cee6fce@timhome2> "Tim Behrendsen"
<tim@airshields.com> writes: 

<snip>
   Well, you say my anecdote says nothing, then turn around and say that
   it requires a "knowledgeable person" to do arrays correctly.  If modern
   compilers are so good that programmers shouldn't have to worry
   about using arrays, then it should have been smart to optimize
   "misuse of arrays".

It takes a knowledgeable person to do anything correctly including
using pointers. The optimizations necessary to make properly used
arrays equivalent in efficiency to properly used pointers are
relatively simple. The optimizations necessary to optimize code that,
say, assumes column major access in C arrays, are equivalent to the
optimizations neceessary for code involving pointers emulating a
multidimensional array, where the innermost loop is associated with
large n strides, while an outer loop is associated with unit
strides. The large strides can result in paging etc. and the code will
typically be much more efficient if the inner and outer loops can be
interchanged, but the compiler can only do that if it is certain that
there are no side effects that are invalidated by such a
reordering. This often requires complicated global analysis.

   The point is, pointers are native to machine architectures, so it's
   going to be easier for the optimizer to produce straightforward
   optimizations if the programmer doesn't do anything dumb by
   creating unsafe side effects.

The point is that with pointers it is more difficult for the compiler
to be certain that the programmer didn't do anything dumb by creating
unsafe side effects. It is not enough for the programmer to not
introduce side effects, the compiler has to verify that he didn't
create side effects. Something that close to the machine can result in
unstructured memory accesses, just as gotos can result in unstructured
flow of control. However, unlike the gotos of most languages, the
unstructured memory accesses associated with C are not easilly
localized. Any pointer used as an argument to a function or as a
global variable, from the computer's point of view, may be aliased
with any other pointer used as an argument to the function or as a
global variable. Unless it can verify that such aliasing has not
occured by doing a complicated global analysis, many optimizations are
disallowed by the language.

Note: Fortran has a reputation for producing faster code than C in
many situations, but untill recently it had only arrays and no
pointers.



-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545

Re: C is 'better' than Ada because...

[Tim Behrendsen]

On Thu, 1 Aug 1996, Byron B. Kauffman wrote:

> Tim Behrendsen wrote:
> > 
> snip...
> > 
> > You are probably right, if you let the optimizer handle everything.
> > But C also gives the capability to do things such as ...
> > 
> > if ((array[++n] = GetValue(arg)) != 0) {
> >     ....
> > 
> > v.s. a typical non-C language ...
> > 
> > n = n + 1;
> > array[n] = GetValue(arg);
> > if (array[n] != 0) {
> >     ...
> > }
> > 
> > Now, which is easier to optimize?  (more snip)
> > 
> 
> Tim, I'm 180 degrees out of phase from you, experience-wise. I've
> professionally done around 10klocs of Ada, and about 24 or so lines of
> C, although I sucked it up and took C++ from a local junior college last
> fall just so I can say that I did.
> 
> With all that in mind, I'm going to ask (in reference to the code
> samples above), which is easier to read and/or maintain? The answer,
> from my C-ignorant perspective, is the non-C example, but a C compiler
> obviously wouldn't have a problem with it. Unfortunately, though, the
> compiler is not the one that maintains or ports the code to another
> platform. IMHO, this is where Ada has the edge over C - it was designed
> primarily with the -ilities in mind. I don't know if it is the industry
> norm, but my primary job description for years was 80% code maintenance
> and rehosting, 20% new code. It is my perception that that is what was
> eating DoD's lunch and why they commissioned Ada.

My statement above is a very common C expression; if you used it every
day, you would think nothing of it.  In fact, I could make a strong
argument that the first example is much more readable/maintainable,
because it's brief and concise.  Too much of the latter, of course, begins
to be a bad thing (take APL, for example).

I certainly don't mean to imply that maintainability isn't important;
in fact, I think it's the *most* important.  If there are significant
gains to be made in that department, then I think Ada has a chance
to succeed out of its nitch.

Having personally written in the neighborhood of 200-300 klocs of C code
(guess? could be more), I think I have a pretty good sense of how things
gets optimized.  My main point, which I think is getting lost in the
swirl of examples, is that in the real world, optimizers aren't that
smart.  Yes, you can find the "super optimizer" that does a good job when
run in "-cape" mode, but in the everyday trenches, I just don't come
across them very often.

There just is no substitute for writing code with an eye toward what
the compiler can and will do with it.

Regards,

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[David Bonham]

Tim Behrendsen wrote:
> if ((array[++n] = GetValue(arg)) != 0) {
>     ....
> 
> v.s. a typical non-C language ...
> 
> n = n + 1;
> array[n] = GetValue(arg);
> if (array[n] != 0) {
>     ...
> }
> 
> Now, which is easier to optimize?  

Well, let's try your example out on a "real world" compiler.  I just 
asked VC++ to compile both fragments and the code generated is
identical.
I wasn't surprised by this - after all, the intermediate representations
of these fragments are probably very similar even before the optimiser
gets its hands on them and I guessed they'd be identical afterwards. 

With optimisation no longer an issue, we're down to factors like 
maintainability and I think you're right to rate these issues highly.

> There just is no substitute for writing code with an eye toward what
> the compiler can and will do with it.

Absolutely.  "A Retargetable C Compiler: Design and Implementation " by
Fraser & Hanson is a real eye-opener when it comes to learning about the
transformations the compiler will make to your source.  

--
David Bonham (bonham@cpd.ntc.nokia.com)

Re: C is 'better' than Ada because...

[Mark McKinney]

"Let the compiler do the optimization ?"
Someone said try it so I did.           
           
Background :  To say that only c does pointer arithmetic 
and Ada does not is not entirely accurate. I wrote a bubble sort using 3 
slightly different techniques. THe second closely resembles c pointer 
arithmetic. Except it should calculate the offset from the original address 
instead of accumulating it. Possible at the expense of a multiply opertion. 
Not used by the c method. 

The concept : Use a simple algorithym use arrays and try to optimize it in 
Ada. Compare the unoptimized results with the optimized results. See which is 
better for the compilers I have access to.

The Test : I chose a bubble sort because it has nested loops so that elements 
of the array would be used over and over. It uses Two different array offsets 
and the swap repeats them.

The Methods : Sort 1 is the standard way of using arrays. Sort 2 attempts 
to use an address clause to eliminat redundant use of array offsets. 
Sort 3 uses a renames clause to for the same purpose. 

The expectation : Sort 2 and Sort 3 should perform better than sort 1 when 
no optimization is used. The results are unpredictble with optimization 
but they should be faster when optimized as well.


The Loops: 
Sort 1 The standard way.

   -- I expect that for each array reference. 
   -- The offset must be recalculated.        
   -- There are Six potential Calculationsbut 
   -- only two are needed.The optimizer should  
   -- use extract common expressions if used. 

   for INDEX_1 in BIG_ARRAY'RANGE loop
      for INDEX_2 in INDEX_1 .. BIG_ARRAY'LAST loop
         if BIG_ARRAY(INDEX_2) < BIG_ARRAY(INDEX_1) then  
            -- Swap                                       
            TMP := BIG_ARRAY(INDEX_1);                    
            BIG_ARRAY(INDEX_1) := BIG_ARRAY(INDEX_2);      
            BIG_ARRAY(INDEX_2) := TMP;                    
         end if;
      end loop;
   end loop;

Sort 2 Declare an Addres clause.
   for INDEX_1 in BIG_ARRAY'RANGE loop
      for INDEX_2 in INDEX_1 .. BIG_ARRAY'LAST loop  
         -- This technique should force the compiler to use one calculation
         -- for each of the two references. 
         declare                                            
            LOW_ADR : constant SYSTEM.ADDRESS := BIG_ARRAY(INDEX_1)'ADDRESS;                         
                  
            LOW_INT : INTEGER;
            for LOW_INT use at LOW_ADR;     -- This is roughly equivelent to poiter arithmetic.

            HI_ADR : constant SYSTEM.ADDRESS := BIG_ARRAY(INDEX_2)'ADDRESS;                          
                 
            HI_INT  : INTEGER;
            for HI_INT use at HI_ADR;
         begin
            if HI_INT < LOW_INT then        -- This is easier to read.
               -- Swap
               TMP := LOW_INT;
               LOW_INT := HI_INT;
               HI_INT := TMP;
            end if;
         end;
      end loop;
   end loop;
           
Sort 3 Use a renames clause.
   for INDEX_1 in BIG_ARRAY'RANGE loop
      for INDEX_2 in INDEX_1 .. BIG_ARRAY'LAST loop
         -- This method only gives the compiler a hint.
         -- The compiler could treat this only as a macro though.
         declare
            LOW_INT : INTEGER renames BIG_ARRAY(INDEX_1);   
            HI_INT  : INTEGER renames BIG_ARRAY(INDEX_2);   
         begin
            if HI_INT < LOW_INT then        -- This is also easier to read.
               -- Swap
               TMP := LOW_INT;
               LOW_INT := HI_INT;
               HI_INT := TMP;
            end if;
         end;
      end loop;
   end loop;


The results :
   All compilations retained expception handling (error_checking).
   Execution times for various compilers.
                  
                            ------ Unoptimized --------   ------ Optimized  --------- 
Compiler                    Sort 1    Sort 2   Sort 3     Sort 1   Sort 2    Sort 3   
                            _________ ________ ________   ________ ________  ________ 
ALSYS DOS (90MHZPENTIUM)      27.8472  19.7731  19.2239    13.5117  19.7731   15.3242 
ALSYS HP 755 (PA-RISC)        37.0996  29.0010  28.9375    21.8467  28.9854   23.8672 
Verdix 3b2                  1417.0000 984.0000 782.0000   815.0000 606.0000  487.0000 
Gnat WIN95/NT(90MHzPentium)   28.9500  27.7400  26.9700     8.0200   6.9200    6.9200 
ALSYS(WIN32)(90MHzPentium)    29.0600  21.6900  21.1500    15.2200  24.6600   24.9300 

   
   Best optimizer show optimization on Sort 1
   Best method shows the most effective combination of sort and optimization for a compiler. 
   
                                  -------- Best -------                                        
                                  Optimizer      Method                                        
                                  _________    _________                                       
ALSYS DOS (90MHZPENTIUM)          206.0973%    206.0973%  Let the optomizer Do it              
ALSYS HP 755 (PA-RISC)            169.8181%    169.8181%  Let the optomizer Do it              
Verdix 3b2                        173.8650%    290.9651%  Combination (Optimizer + Sort 3)     
Gnat WIN95/NT(90MHzPentium)       360.9726%    418.3526%  Combination (Optimizer + Sort 2 or 3)
ALSYS(WIN32)(90MHzPentium)        190.9326%    190.9326%  Let the optomizer Do it              
                              

Conclusion :
   If highest performance is a requirement for a routine. Try and test differnt techniques. 
   I suspect this applies in any programming language. Idealy you should pick a compiler that 
   meets this requirement. Different implementations of a language can have different results. 
   Use a test that meets your requirements.(Event though the pentium machine outperforms the HP in
   this test text reports genrated off of flat files in both C and Ada are about 60 times as 
   fast on the HP as The Pentium Better Io?)
   The "I'll be sure and code it in assembly" argument has merit when justified by requirements. 
   I you care about performance find many compilers and test them on the target platform. 
   
Surprizes :
   In the case of the ALSYS compilers it is clearly better to let the optimizer do the work.
   GNAT Did exceptionally well. (I haven't used it much I'll use it more, if Someone can help 
   me get the Windows API to compile correctly)    

Comments :
   A better optimization would be to use a better sorting algorithym. Generally this should 
   be tried first.
   
   There is no substitute for hard work if you really want to know.

   These test results are not intended to endorse any particular product. The test 
   were done hastily and in less than Ideal conditions. Let your system requirements 
   determine which compiler you choose using appropriate test cases.

   Any opinion are mine and mine alone.
   All other disclaimers apply.
   
   If you want complete source I'll send it. 
   send requests to mckmark@mail.concentric.net

             Mark McKinney

Re: C is 'better' than Ada because...

[Tim Behrendsen]

On Tue, 6 Aug 1996, Richard G. Hash wrote:

> In comp.lang.ada you write:
> > if ((array[++n] = GetValue(arg)) != 0) {
> >     ....
> > v.s. a typical non-C language ...
> > 
> > n = n + 1;
> > array[n] = GetValue(arg);
> > if (array[n] != 0) {
> >     ...
> > }
> > Now, which is easier to optimize?  (more snip)
> 
> Do you actually use a modern C compiler that optimizes these two
> constructs differently? I've used recent C compilers on half a dozen
> platforms, and find it really difficult to believe there is any
> difference...
> 
> What compiler/platform are you using?

The original post has been corrupted somewhat; this was an example
of how C's syntax provides some dataflow hints to the compiler for
optimization.  Originally I said "A modern compiler will probably
produce the same code", but that part got lost way up in the tree
somewhere.

-- Tim Behrendsen (tim@airshields.com)

Re: C is 'better' than Ada because...

[@#$%!?!]

: Unfortunately, it's very difficult to find good examples of things
: that are difficult to optimize, because a case can always be made

It is quite easy. For any language.

There are two parts of an optimiser: (1) can I change this program?
and (2) this is how I will change the program. Part (2) is easy.
Part (1) can range from easy to provably impossible. A simple case
would be a nonFortran subroutine that has to be vectorised independently
of its caller,

	copy array A to array B is
	    for i from lwb of A to upb of A do
		copy A[i] to B[i]

Fortran requires A and B refer to distinct memory areas, so this is
immediately vectorisable. But in every other language without an alias
ban this is nonvectorisable without some additional information. The
more information the language provides, the better the optimiser can
do part (1).

If the processor has two or more add pipes, it can do two additions
for the price of one. So if you have (a+b+c+d) it can be two thirds
as fast to compute ((a+b)+(c+d)) instead of (((a+b)+c)+d). However
addition does not reassociate in Fortran or C, so the optimiser is
prevented from reparenthesising. The fewer constraints the language
imposes, the better the optimiser can do part (1).

-- 
In mirrored maze he met the Mother,        | smryan@netcom.com  PO Box 1563
the lost and breathless, lonely brother.   |          Cupertino, California
Both crone and child, now crying wild,     | (xxx)xxx-xxxx            95015
her clinging clay will clothe and smother. |         I don't use no smileys

Re: C is 'better' than Ada because...

[Adam Beneschan]

Craig Franck <clfranck@worldnet.att.net> writes:

 >The point I was tring to make is you can write bad code in any 
 >language. Good programmers and software support are as important
 >as the language. Puting training wheels on a language by being 
 >able to write : FOR I IN Data 'RANGE LOOP
 >                  Put(Data(I), 3);
 >                END LOOP;
 >because programmers can't count, may be helpfull.

I haven't been following this "Thread That Will Not Die", so maybe I
don't understand the context in which this statement occurs.

It seems to me, though, that the poster is referring to 'RANGE as
"training wheels" designed to protect inexperienced programmers from
accidentally typing the wrong loop limit.  This is ridiculous and
shows a complete lack of understanding of software engineering
principles.  The whole purpose of 'RANGE, 'FIRST, 'LAST is for
*maintainability*.  It's there so that if you later decide to change
the bounds of Data, you can do so in ONE PLACE (the place where Data
is declared) without affecting the correctness of the rest of the
program.  

Having the same information in two or more places in the program has
long been recognized as a major source of errors introduced during
maintenance.  That is, if you say

    Data : array (1 .. 3) of whatever;

. . .
    for i in 1 .. 3 loop
       Put (Data (i), 3);
    end loop;

the lower and upper limits (1 and 3) are information that occurs in
two places.  Not a good idea; if you change one and forget to change
the other, your program suddenly doesn't work any more.

In fact, I'd consider an Ada programmer that coded the above loop to
be an inexperienced one.  I've been programming for 20 years, 8 years
in Ada, and I would ALWAYS use the 'RANGE construct that this poster
denigrates.  It is *not* a "training wheel."

                                -- Adam

Re: C is 'better' than Ada because...

[Craig Franck]

adam@irvine.com (Adam Beneschan) wrote:
>Craig Franck <clfranck@worldnet.att.net> writes:
>
> >The point I was tring to make is you can write bad code in any 
> >language. Good programmers and software support are as important
> >as the language. Puting training wheels on a language by being 
> >able to write : FOR I IN Data 'RANGE LOOP
> >                  Put(Data(I), 3);
> >                END LOOP;
> >because programmers can't count, may be helpfull.
>
>I haven't been following this "Thread That Will Not Die", so maybe I
>don't understand the context in which this statement occurs.
>
>It seems to me, though, that the poster is referring to 'RANGE as
>"training wheels" designed to protect inexperienced programmers from
>accidentally typing the wrong loop limit.  This is ridiculous and
>shows a complete lack of understanding of software engineering
>principles.  The whole purpose of 'RANGE, 'FIRST, 'LAST is for
>*maintainability*.  It's there so that if you later decide to change
>the bounds of Data, you can do so in ONE PLACE (the place where Data
>is declared) without affecting the correctness of the rest of the
>program.  

"Training wheels" was a poorly chosen phrase. The fact that a language
would have built in support for not running past the bounds of an array
should not be cause for belittlement. Perhaps "guard rails" would have
been better. And yes, programmers can count -- but what it is they are
counting can change. I still find the syntax for attributes strange.

> I've been programming for 20 years, 8 years
>in Ada, and I would ALWAYS use the 'RANGE construct that this poster
>denigrates.  It is *not* a "training wheel."

Though Pascal was designed to stop inexperienced programmers from shooting 
themselves in the foot, Ada is not Pascal.


Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

Re: C is 'better' than Ada because...

[Mike Roske]

Adam Beneschan wrote:
> It seems to me, though, that the poster is referring to 'RANGE as
> "training wheels" designed to protect inexperienced programmers from
> accidentally typing the wrong loop limit.  This is ridiculous and
> shows a complete lack of understanding of software engineering
> principles.  The whole purpose of 'RANGE, 'FIRST, 'LAST is for
> *maintainability*.  It's there so that if you later decide to change
> the bounds of Data, you can do so in ONE PLACE (the place where Data
> is declared) without affecting the correctness of the rest of the
> program.
> 
> Having the same information in two or more places in the program has
> long been recognized as a major source of errors introduced during
> maintenance.

Exactly.  And this same problem occurs in both C _AND_ Ada language
programs.  Ada gives you a nice way to avoid it, but engineers who
write structured software will use preprocessor definitions in C to
define _in ONE PLACE_ size (and other) information about data structures.

Ergo, as both languages provide a mechanism to solve the single
definition problem, neither is "better" in this category.

-- 
*-------------------------------------------------------*
* Michael Roske
* Sanders, A Lockheed Martin Company
* mroske@mailgw.sanders.lockheed.com
* (603) 885-9240
*-------------------------------------------------------*
* "I'd rather be flying RC..."                     
*-------------------------------------------------------*

Re: C is 'better' than Ada because...

[William C Brennan]

In article <321AE6D8.41C67EA6@mailgw.sanders.lockheed.com>, Mike Roske
<mroske@mailgw.sanders.lockheed.com> wrote:

> Adam Beneschan wrote:
> > Having the same information in two or more places in the program has
> > long been recognized as a major source of errors introduced during
> > maintenance.
> 
> Exactly.  And this same problem occurs in both C _AND_ Ada language
> programs.  Ada gives you a nice way to avoid it, but engineers who
> write structured software will use preprocessor definitions in C to
> define _in ONE PLACE_ size (and other) information about data structures.
> 
> Ergo, as both languages provide a mechanism to solve the single
> definition problem, neither is "better" in this category.

Well, both C and Ada do supply a mechanism to support a centralized, 
single-point name definition for the upper-bound or size of an array 
(or of an enumeration type, etc).  But this does not mean that C's and Ada's
mechanisms are equally "good".

The C mechanism requires the programmer to define new names for the
upper-bound and size.  For one thing, this just unnecessarily pollutes the
name space.  It also puts the extra onus on the programmer to maintain
the connection between an array type name and its upper-bound name.
Standards may be employed by the staff to make this a simple mapping
(e.g., "NameArray" and "NameArrayMax"), but I've never seen standards like
this actively enforced in a project.  

One reason it isn't even this simple has to do with C's 
null-terminated strings. where you may need up to three constants:
size of the array, upper-bound of the array, maximum number of
non-null characters in the array.  This sometimes means making up 
3 names and keeping their uses all straight.

The Ada mechanism embeds the naming convention into the language,
so that its use is consistent throughout (e.g., "NameArray" and
"NameArray'Last").
The compiler actually understands the meaning of "NameArray'Last", it's not
some relationship the programmer needs to maintain as in C.

The Ada mechanism enforces consistency, and keeps the size of the 
name-space down.  This is cleaner and to my mind "better".

-- 
Bill Brennan
brennanw@pond.com