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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5992229ab824d8f7 X-Google-Attributes: gid103376,public From: stt@henning.camb.inmet.com (Tucker Taft) Subject: Re: Q: on redefinition of "= Date: 1996/04/03 Message-ID: #1/1 X-Deja-AN: 145607025 sender: news@inmet.camb.inmet.com (USENET news) x-nntp-posting-host: henning.camb.inmet.com references: <4jrlluINN15b@thalamus.cis.ohio-state.edu> organization: Intermetrics, Inc. newsgroups: comp.lang.ada Date: 1996-04-03T00:00:00+00:00 List-Id: david scott gibson (dgibson@thalamus.cis.ohio-state.edu) wrote: : ... : While I certaily see how this is useful for performance critial : applications, I'm not convinced that this is a particularly good : characteristic for a "software engineering" language. Ada supports : abstraction nicely in many ways. The notion that a programmer needs : to be thinking in terms of how language constructs are implemented : seems less than ideal. During the Ada 9X revision process, we had to make a conscious choice about what kind of language was Ada. Our conclusion was that Ada was primarily a "systems implementation language," where programmers care deeply about the time and space performance of their programs. Of course you can use a language any way you want, but when designing the language, we felt it was important to have a clear design philosophy which could guide tough decisions. So Ada 95 was designed primarily for programmers who care how things are implemented. Programmers who don't care have it easy, of course. For those who do, it is important to understand, almost to the point of "intuition," the relative expense of various language features. The ideal (in my view) is that all "primitive" features of the language be extremely efficiently implementable, and the sources of inefficiency all be those of the programmer's own making. However, even with the best of intentions, certain features (or interactions, such as exceptions+finalization) do end up inducing more overhead. For those features, it is important for the unlucky programmers who *do* care about space/time performance that they be aware of this overhead. As one final comment, I personally believe that a *big* part of software engineering is satisfying the time/space requirements. Perhaps we have all gone soft in an era of rapidly increasing hardware speed and RAM, but in my experience, customers still care deeply about time/space performance, and if the hardware gets faster, they want their code to run faster too, not just bloat out to take up all the extra MIPS/MBytes. Sorry to sound so "preachy" here, but too often I hear this notion that you can ignore performance issues during "software engineering" and tune the code when you are done. In any big system, I have *never* found this to be the case. If you want the system to be fast, you have to design in high speed and a small (virtual) memory foot print. You can't just "tune" it. The old 90/10 rule is misleading in my experience, because the 10% of the code in which you spend 90% of the time, or consume 90% of the space, is spread all over the place, and after even a little "tuning," no single routine consumes more than 5% of the time/space. : Dave : dgibson@cis.ohio-state.edu -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA