From:  Roger Racine <[log in to unmask]>

> I obviously did not word the argument well.  I will try again.

OK, I won't bother addressing the earlier formulation of the argument!
:-) Without having read them in detail, it looks like earlier
respondents have clobbered that pretty throroughly, and their objections
are probably pretty similar to mine...


>  By the way,
> these are close approximations to two real projects of the same type
> (guidance, navigation and control).

I guess that's good news and bad news.  One the one hand, we aren't
dealing entirely with a hypothetical, straw-man (no pun intended :-)
argument.

On the other hand, we are now trying to generalize from a miniscule
sample space and no controls.  I suppose that some of the illogic and
difficulty in expressing the argument is a result of trying to
articulate a principle where in fact there is no single overriding
principle (at least, no Ada-vs.-anything principle) in operation.  One
project came out OK and one came out crappy, but the faith that there
will turn out to be an Ada-vs.-C connection may be misplaced.


> It is always conceded (please give me experience otherwise)
> that Ada costs more to design and code than C

Why is that "conceded?"  It certainly hasn't been my experience,
although I can't quantify it (and even if I could, I'm still just one
individual).

> In my opinion and experience, Ada does not lend itself well to rapid
> development.

I disagree!

> 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.

Nothing that you do when prototyping is supposed to "help" you "later
on".

One of the key principles of prototyping is that you THROW AWAY THE
PROTOTYPE(S).  This principle is too often ignored, but attempts to
"leverage" the prototype dilute its effectiveness as a prototype and
compromise the integrity of the delivered system.  A prototype serves as
a mock-up of some aspect of the system.  It can be as deep/shallow or
wide/narrow as you need it to be, but it's not a direct step toward the
delivered system.  It's a learning tool.  The prototype need not even be
written in the same language as the delivered system, e.g. for a
UI-intensive application you might choose Java for prototyping even if
the delivered system were to be written in Ada.  I would choose Ada,
Smalltalk or Java ahead of C/C++ as a rapid prototyping language.

Iterative development isn't the same as prototyping.  Each iteration
is supposed to produce a robust, production-quality system that fulfills
some predetermined subset of the project requirements.  The deliverables
in an iterative process are not prototypes -- they are fully tested
(with respect to the target requirements subset) and integrated
instances of the system.

Iterative development, like the waterfall model, is a method.
Prototyping isn't a method; it's a technique that can and should be
used along with iterative development.  The overall aim is the same --
namely, risk reduction.

>
> There is a higher cost-overrun risk using Ada than using C, C++ or Java,
> due to the extra work done to generate the Ada code.  A good development
> process will help lower the risk, but not get rid of it.
>

I still don't understand this argument...  The other points mentioned
don't establish that there is any "extra work" in writing Ada code vs.
<language X> -- it seems to be taken as an axiom.


Best regards,


Mark Lundquist
Senior Software Engineer
Rational Software
Development Solutions Business Unit
UNIX Suites Group
Aloha, OR, USA