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