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

[ian@rsd.bel.alcatel.be (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