From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,dab7d920e4340f12 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,dab7d920e4340f12 X-Google-Attributes: gid1014db,public From: ian@rsd.bel.alcatel.be (Ian Ward) Subject: Re: C is 'better' than Ada because... Date: 1996/07/29 Message-ID: <4thn28$krj@btmpjg.god.bel.alcatel.be> X-Deja-AN: 170777450 distribution: world references: <01bb7bfc$3c5ca460$96ee6fcf@timhome2> organization: Alcatel Bell Telephone reply-to: ian@rsd.bel.alcatel.be newsgroups: comp.lang.ada,comp.lang.c Date: 1996-07-29T00:00:00+00:00 List-Id: In article 96ee6fcf@timhome2, "Tim Behrendsen" () writes: >Ken Garlington 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