Re: Q: on redefinition of "=

[stt@henning.camb.inmet.com (Tucker Taft)]

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