Re: Time to join the fold?

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

Mike Silva (mjsilva@jps.net) wrote:

: ...
: Now for my questions (all assuming that I determine that switching to Ada is
: a good idea).  First, how long would it take me (a long-time C [and a bit of
: C++] programmer) to get productive in Ada?  

Not long.  If you tend to be a C programmer who writes one ".h"
file for every ".c" file, and who tries to minimize the amount of
information exposed in the .h file, then you already know the fundamental
idea of a package and a private type, with a separation between package 
spec and body.  Using packages right is really the key to using Ada,
and to some extent using appropriate modularization via .h/.c pairs
is the key to using C right.

One of the great things about Ada is that the compiler is so picky,
that it helps you learn the rules of the language more quickly.
You can make that even better by minimizing your use of predefined
numeric types like "Integer," but instead defining your own numeric 
types with the appropriate range.  Then the compiler will help more in
catching the use of the wrong type as an array index, or the wrong
type passed to a function or procedure.

: ... Second, what is the best way to
: present the case to my boss?  He's open-minded, but switching to a new
: language that I don't know is bound to require plenty of justification.  

Almost all of the Ada 95 compilers have excellent interoperability with
C.  Rather than trying to rewrite the whole thing right away, pick
a well defined abstraction (i.e. one of those .h/.c pairs), and rewrite
that in Ada.  For fun, you might want to pick one that has been a major 
source of bugs in the past.  For simplicity, pick one that has relatively
few external interface points exposed in the .h, but plenty of groddy
internal interactions in the .c.

Or pick a new abstraction associated with some particular enhancement,
and write that part in Ada, while the main part of the program is still
in C.

: I know of most of the main Ada web sites and the success stories and "why Ada"
: articles they have, but I was wondering if some of you might have further
: opinions and/or experiences in "converting" a project or company to Ada.

Start with a small piece, and work up slowly.  Try to keep track of
how many bugs are caught by the compiler, caught by run-time checks,
or left to you to track down at run-time.  I think you will be very
impressed with how few bugs make it through to the painful debugging
stage.  A remarkable percentage of mistakes, sometimes even relatively
deep "logic errors," are caught by the compiler and the compiler-generated 
run-time checks.

My usual analogy is giant slalom gates on a ski slope.  Any hacker
on skis can make it through one giant slalom gate.  But if you
start to pepper the slope with slalom gates, only a skier who has
a deeply correct approach to skiing can make it through them all.

Each compile-time and compiler-generated run-time check is trivial
in its own right, just checking that two types match, or that a value
is in some range.  But for a program to make it all the way through
all of these consistency checks, it needs to be internally consistent
and logical in a deep sense.  Otherwise it is almost certain to be
tripped up by one of these "trivial" checks.  And based on empirical
experience, a program with a bug generally gets tripped up by
one of these checks remarkably close to the source line where the
underlying flaw resides.

: Thanks a bunch for any insights.

: Mike Silva

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA