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.1 required=5.0 tests=BAYES_05,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a3782bc93aeb7709
X-Google-Attributes: gid103376,public
From: mfb@mbunix.mitre.org (Michael F Brenner)
Subject: Re: Just a question...
Date: 1996/04/17
Message-ID: <4l3hlk$7m4@linus.mitre.org>#1/1
X-Deja-AN: 148038906
references: <4l32nn$mqn@boson.epita.fr>
 <4l350u$grc@ns1.sw-eng.falls-church.va.us>
organization: The MITRE Corporation, Bedford Mass.
newsgroups: comp.lang.ada
Date: 1996-04-17T00:00:00+00:00
List-Id: <comp.lang.ada>

One piece of advice is to demand the same quality of tools in your
new language as you used in your old language, use the best 
design methods, and the best test methods. 

Second, build a self-test into each package.

Third, follow the Ada methodology of integrating the entire system
together through the package visible parts before hacking more than
about 50% of the code, so that you will gain the benefit of lessened
integration testing later. 

Fourth, avoid the temptation of having too many levels and too many    
incompatible types; there has to be a balance. My current (very humble)
opinion is that the Ada Numerics are very well balanced, and that the
Ada Stream_IO capability has far too many levels, which is a starting
point to defining this Balance. 

Fifth, avoid the nostalgia of doing everything as a pointer, which is
no longer needed since Ada does that for you internally in many cases.

Sixth, buy a commercial Ada compiler to check your gnat execution speed
against, and to keep driving the industry to better optimizations.

Seventh, publish some well-measured results of your experience in 
reducing system integration test and software maintenance times: Keep
a Measurement Record Now.