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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a3ca574fc2007430 X-Google-Attributes: gid103376,public X-Google-Thread: 115aec,f41f1f25333fa601 X-Google-Attributes: gid115aec,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: Ada and Automotive Industry Date: 1996/11/11 Message-ID: X-Deja-AN: 195794370 distribution: world references: <55ea3g$m1j@newsbf02.news.aol.com> <3280DA96.15FB@hso.link.com> <1996Nov6.210957.3070@ole.cdac.com> <32812D6B.ABD@hso.link.com> content-type: text/plain; charset=ISO-8859-1 organization: Estormza Software mime-version: 1.0 newsgroups: comp.lang.ada,comp.realtime Date: 1996-11-11T00:00:00+00:00 List-Id: In article , ken@nrtt.demon.co.uk wrote: >There's quite a lot in Ada that does indeed imply >bad performance. Quite a few optimization techniques >are disallowed because of the elaboration and >evaluation rules (see papers by Mike Kamrad for >examples). Even if that's true, there are many instances when Ada is faster. A programmer can communicate more semantic information to the compiler because of Ada's rich typing, and the compiler is therefore able to make *more* optimizations than otherwise would be possible. >> [code size issues snipped] >You still miss the point. If Ada implementations costs >20% more code space then that's a few cents per unit. >But a few cents per unit added up over millions of >units adds up to a lot of money. But there's a hidden assumption here, an assumption I see over and over again whenever there's criticism of Ada (or any other high-level language). It's that you assume you can actually do the job using some other language. For a complex system, what makes you so sure you can do the job at all? What makes you so sure you can maintain intellectual control of your software solution to a complex problem, without using the facilities proffered by a high-level language? Do you realize how many software projects fail? Ever heard of the Therac-25? As has been said, software engineering is really the process of finding abstractions. Or more to the point, it's finding the tools and techniques that help *humans* write software. Ada was designed with the philosophy that programming is a human activity. The Ada language is a tool that facilitates the construction of software systems by human programmers. Having software tools like Ada allows the same programmer - as any other worker - to be more productive, and to construct a more complex system than without the tools. That Ada somehow inherently creates larger object code, or inherently creates less efficient code, is a specious argument that is not supported by facts. Modern Ada compilers are at least as efficient in terms of code size and execution speed, as has been demonstrated empirically. Lest you think I make empty claims about Ada's efficacy as a software engineering tool, then read the following articles: >> [Ada "complexity" issues snipped] >It's not a red herring. Ada is hugely complex, and not >well understood. If you think that Ada is elegant and >consistent then you don't understand it very well. You >only have to look at the "Dear Ada" column in ACM >Ada Letters to see this (I really recommend you do >read the column!). Ada is not hugely complex. It's very logical. Just do what you think makes sense, and all is well. The trick is "thinking in Ada." That's sometimes a problem because there are many programmers who don't think in terms of abstractions, who don't understand information hiding, and who don't know what the contract model is. But this is a programmer problem, not an Ada problem. As I've said, Ada is a tool to help the software engineer. For the programmer who dismisses modern software engineering philosophy and practice, Ada won't help, and may even seem like a hindrance. As they say, "garbage in, garbage out." Perhaps the person who said that Ada is "Pascal for lawyers" was intimidated by the Ada Reference Manaual (RM). I myself am intimidated at times. However, that book is for compiler writers, not programmers. You see, the compiler has to handle every case; it needs to have defined behavior even for input that doesn't make any sense, for things Joe Programmer would never do in practice. Thus the seeming complexity. (Although I've heard that the C++ RM is even larger.) When I program in Ada, I never need to consult the RM, except to look up what exceptions get raised by a predefined library unit. Usually, the text I submit to the compiler compiles the first time. So where's the complexity, exactly? Just do what seems right, and all is well. You do not need to be a language lawyer to program in Ada, in spite of claims to the contrary. And yes, I do read the Dear Ada column. And somehow I've come to a different conclusion than you. > >Tony Hoare once said that one of the keys to success in language >design was to make it so simple that there are obviously no >deficiencies. The other way is to make it so complicated that >there are no obvious deficiencies. Interesting, because Ada's tasking model was heavily influenced by Hoare's CSP. "No obvious deficiencies" sounds like the problem C++ is having right now; it certainly doesn't apply to Ada. If there were ever a language that requires a lawyer, it's C++. For a litany of its many trap doors, read this critique by Ian Joyner: >> [Ada tasking issues snipped] >It is impossible. Ada 83 tasking cannot be used reliably for real-time >(as the Boeing people above mentioned). Ada 95 tasking still leaves a big >efficiency problem, which is crucial to the automotive industry, >where a few cents on a control unit add up to millions over a product >life. My understanding is that Ada 95's protected types are just as efficient (or more so) than the lower level but unsafe mechanisms used in other languages. While Ada tasks may seem relatively heavy, with the existence of protected types, how many Ada tasks do you really need? Once again, on what basis are you able to say that a correctly engineered Ada program - even one with tasks - is less efficient than a comparable system written in another language? >The only role for Ada in the automotive industry is in areas where cost >is not important, and where there is a significant improvement in >reliability over existing languages. Obviously, cost is always a factor in any engineered system. But what is the cost when someone dies because of a software error? When a crisis like that does occur in the automobile industry, then I bet no one will complain about how much Ada "costs" (as if it were really more) if it can save lives. You know, you sound like someone who's afraid Ada will be used in the automotive industry. I think thou protest a bit too much. What are you so worried about? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant mheaney@ni.net (818) 985-1271