TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To: "W. Wesley Groleau x4923" <[log in to unmask]>
Date: Tue, 14 Apr 1998 02:39:24 -0400
Reply-To: Steven Deller <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
From: Steven Deller <[log in to unmask]>
Parts/Attachments: text/plain (77 lines)
For typos, you do not need full compilation so compilation speed should
not be an issue.  Apex's Ada editor can point out syntactic errors as you
enter them, or even be configured to fix the simpler ones.  A simple
semantic scan (not a full compile) can quickly identify typos that are
syntactically valid.

For what it is worth, I think the time to recompile and relink a fully
working program with a number of changes is far more interesting to have
fast than the time to compile the code the first time.

If compilation speed is important with the first compile before a program
is working, it can be argued that indeed there is sloppy "let the
compiler find it" thinking going on.

On the other hand, once an application is working, it is prudent to make
modifications in controlled increments.  One expects each increment to
have been reviewed carefully, but it often takes little time to repair
many of the problem reports against an application.  Being able to
rebuild and retest after each incremental change can greatly reduce
confusion during maintenance of a program.

Coincidentally, Apex takes a longer initial compile time precisely to
produce artifacts aimed at reducing subsequent compile and link times for
very large programs.  But I'm sure you knew this.


Steven Deller, Apex Ada Marketing Manager
[log in to unmask], (703) 709-6437
Rational Software Corporation,

On Monday, April 13, 1998 5:09 PM, W. Wesley Groleau x4923
[SMTP:[log in to unmask]] wrote:
> > >  Contrast this method with the more common approach where once the
> > >  program is coded, the engineer immediately tries to compile it.
> > >   The
> > >  compiler then leads the engineer by the nose from one problem to
> > >  the
> > >  next.  When the program finally compiles, the engineer is so
> > >  relieved
> > >  that the immediate desire is to see if it will run.  One of the
> > >  best
> > >  clues that a shop follows this approach is complaints about how
> > >  slow the
> > >  compilers are."
> > >
> > >                                -- Watts S. Humphrey
> > >                                   A Discipline for Software
> > >                                   Engineering
> On the other hand, ....
> I make lots of fat-fingered* typos.  Half of them I catch myself before
> I
> get to the next line.  The other half, I just can't for some reason see
> them until either a couple of days have elapsed or the compiler points
> them out.  Now if I were to discipline myself to not touch the compiler
> until after peer review, I would be wasting the time of all the
> reviewers.  Plus probably missing some "real" defects because the
> reviewers are distracted by all the nits.  (I say "real" because a
> program
> that won't compile can't crash the system.)
> It is counter-productive to stare at a printout or screen for twenty
> minutes and see nothing wrong, when a compiler can tell you in twenty
> seconds that you have an apostrophe where you need a semicolon, or an
> extra parenthesis, or ....
> But as soon as (or even before) all the typos are fixed, a genuine
> review
> would certainly be a good thing.
> * you can call 'em fat-headed if you want, I'm think-skinned (or
>   thick-headed)  :-)