TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
"(No Name Available)" <[log in to unmask]>
Date:
Sun, 23 Mar 1997 00:30:53 -0500
Reply-To:
Parts/Attachments:
text/plain (24 lines)
Richard Riehle [log in to unmask] writes:

>At the end of a two month class (two nights per week, and two
>Saturdays) in Ada, one of my more argumentive students approached
>me with his view of Ada.  He said, "I think I am beginning to see
>the point. With C I can get a clean compile on my program immediately,
>but it takes me a long time to get it to run.  With Ada it takes a long
>time to get a clean compile, but once it compiles there is less work
>required to make it run."

That is the first half of the prime virtue of Ada.  The second half is
that
compile-time error messages are guaranteed to be issued while the code
is still in the hands of the programmer, rather than in the hands of the
user.

Tasking and numeric precision may be useful extras for certain projects
(and those projects may have funded a lot of compiler development), but
the average programmer is _always_ a likely victim for the "find out at
runtime even if via machine fault" issues.  Ada programs may have such
errors also, but in vastly smaller quantities.

Larry Kilgallen

ATOM RSS1 RSS2