Roger Racine wrote:
> ...
> Pretty much all the arguments in favor of Ada assume a fairly expensive
> front-end load to development costs, no matter what process is used.  The
> arguments I have used and heard for Ada are all about integration and
> maintenance. It is always conceded (please give me experience otherwise)
> that Ada costs more to design and code than C

I don't agree with that, and it is a big mistake in my view
for the Ada community to continue to emphasize only long-term savings while
ignoring short-term issues.  It is pretty clear that time to market is
the most important criteria in most commercial software development
activities these days.   I believe that Ada can be used in a prototyping
mode, and still provide significant benefits, in ease of debugging,
ease of reading, compile-time error detection, etc.

> ... (and, by extension C++ and
> Java.  Not that these last 2 are known to be true, but people do make that
> extension).

Once you get into object-oriented programming development, the argument
breaks down, in my view.  To do anything sensible in an
OO development, you need to think in advance about the class hierarchy,
etc.  I would say that the "just start coding" approach is really only
possible in methodologies designed for languages like C and Fortran where
you can build up a program out of a "bag" of functions.  Interestingly,
you can also write Ada prototypes as a "bag" of functions, and you
would still get the benefits of null pointer checks, array bounds
checks, etc.  C++ can also be used with the "bag of functions"
approach if used simply as a "better C."

The thing is, I can't imagine anyone building anything signficant these days
using the bag-of-functions approach.  Even in C, breaking the program into
files in an appropriate way is essential to being able to build even a medium
size program.  So I have to believe that if project C got to execution of a
significant prototype relatively quickly, then project A could have done
the same thing, taking the attitude that some or all of it might be
thrown away.  Perhaps the mistake with project A is that they overengineered
their prototype.  Perhaps that is the Ada disease -- not being willing
to throw the first one away, if necessary.

I guess my key point is that you can be just as fast-and-loose in
Ada as in C when appropriate, and you still get a number of advantages
due to the run-time checking.  Then you can start defining more appropriate
types, packages, etc., and start getting the additional compile-time checking
advantages that C won't ever provide.

> ...
> In my opinion and experience, Ada does not lend itself well to rapid
> development.  Defining the types, laying out the packages, etc., take time
> up front.  Yes, one can use the predefined types for all data, but then
> Ada's strong typing will not help in integration and maintenance.  And
> packages can be created that just hold a bunch of procedures and functions,
> as in C files, but then Ada's modularity features will not help in later
> phases.  ...

I have to believe that even project C spent some energy defining
C structs, and organizing procedures and functions into files.
If they spent no energy on either of those activities, then
they were miracle workers to even get a prototype working, in my
experience.  Perhaps the difference is again that the project A
tried too hard to get things exactly right first, whereas project
C took a more pragmatic, give-it-a-try attitude.  You mention
incremental development, but that is not the same thing as prototyping
in my view.  The goal of incremental development is to have something
working early, and then add functionality incrementally.  The goal
of prototyping is to build something quickly that helps inform
requirements and/or design decisions before committing on the final
design.

So I think the main lesson to be learned here is that prototyping
is important, even when programming in Ada, to make sure that
the requirements and design issues end up well understood before making a
major dollar commitment.  Ada can be an excellent language for rapid
prototyping, so long as you admit you are not trying to get everything
perfectly structured in advance.

> Roger Racine
> Draper Laboratory, MS 31
> 555 Technology Sq.
> Cambridge, MA 02139
> 617-258-2489

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