"W. Wesley Groleau x4923" <[log in to unmask]> 09/05/97 01:34pm quoted the following: >----- Begin Included Message ----- >.... > Programming language selections should be made in the context of > the system and software engineering factors that influence > overall life-cycle costs, risks, and potential for > interoperability. The selection factors should be reviewed > by the program Integrated Product Team (IPT). I am struck by how on target this paragraph is with respect to what *should be done*. No one in their right mind would dispute the necessity of this. The *issue* has always been: *will it be done*? I honestly don't know one way or the other, but I keep getting hints that it is not too hard to fudge the above idealism in plausible (hence successful) ways. > Among the factors the IPT should considered are: > > . extent of compliance with/incorporation or other related > direction (e.g., ATA, open systems, and > commericial-off-the-shelf software) and the impact hereof; Feels like there's a word missing in there somewhere, but it sort of looks like this is talking about the issue of bindings. Assuming I'm decoding it correctly: How's ARA/SigAda/whatever-entity-was-supposedly-on-top-of-this-problem coming on standardizing and producing bindings for the various things that need to be interfaced to? If bindings aren't available, companies like mine (at least the part that used to be its own company a month ago) ain't all that interested in writing their own. Even though I suspect some people grossly overestimate the difficulty of writing bindings (I've written a few myself), there are most likely better reasons why we don't write them ourselves. This might be one criteria where it is conceivable that C++ could be better than Ada(95). > . long-term maintenance implications, including evolvability, > supportability and lowest life-cycle operations and sustainment > (O&S) costs; Even in Don Reifer's flawed comparison of Ada and C++/C, his numbers showed an advantage for Ada 83 over C and C++ (the sample size was too small for Ada 95 as I recall) in the above mentioned areas. I note simply that it is my understanding that Ada was designed in the first place with this in mind, among other things. > . software reuse; Was it not also designed with this in mind as well? > . system/software requirements, including performance, > interoperability, reliability, safety, and security requirements; And these? > . system/software architecture, including partioning into > components; Also these, though it seems like some of this was also addressed by Ada9x? Is there still a delay in bringing these features to the marketplace, or are we seeing compilers and tools supporting this stuff now? Are we still bucking the false myth that Ada 95 is brand new technology? > . selection of software development and support methodologies and > processes; Honest, non-polemical question: Aren't these issues largely language independent? > . use of software development and support tools and generators; This has always been where Ada has the weakest reputation - deserved or otherwise. And in fact it is one thing that cannot be completely addressed when designing a language. It can be impacted I suspect, but not completely determined. So here is another area in which C/C++ might conceivably beat out Ada. > . integration of software issues and decisions with other planning > considerations to include cost, schedule, acquisition strategy > and staffing. Cost used to be a deciding factor for C/C++ over Ada, but as someone pointed out, when you compare commercial costs for C/C++ versus Ada, it is misleading to just compare compiler to compiler, because with C/C++ you need additional tools to do things that are included in the Ada compiler. Nowadays I hear more about how one Ada vendor is significantly cheaper than another, but not so much C/C++ cheaper than Ada. Staffing has suddenly reared its ugly head ('round these parts at least) as a C/C++ point-winner: "There aren't enough Ada programmers available". Maybe Mike Feldmann has a handle on whether that's because few recruits *know* Ada or few recruits *want* to do Ada. In terms of the former, *I* learned Ada from scratch in one week and had no problem growing into the language, and I had never even been exposed to it before. Anyone who is good enough at C++ to put it on a resume should be able to learn Ada. >----- End Included Message ----- I guess my point is that with possibly one or two exceptions, wasn't each of the above criteria uppermost in the minds of the designers of Ada and the DoD entity that contracted for the language 20 years ago as the answer to the Software Crisis? Weren't those who designed the language all experts in the field with years of experience in doing things like this, and for all the difficulties they might have experienced coming to consensus wasn't the end product still worthy of respect? And now for a year or so the DoD *and* the leadership of the Ada community itself have been saying that all the above criteria should be assessed by each DoD project individually on a case-by-case basis. Again, I emphasize, this sounds impressively intelligent (no sarcasm intended). But there is one insidious reason available to DoD projects who are presented with these criteria: The answer to these questions *used* to be Ada, period. Now, it only *might* be. "Something must be wrong with Ada! Why else the shift?" In the meantime, the challenge to the Ada community (if it decides to accept it) is to ask, and keep asking until an answer is forthcoming: How is C or C++ better than Ada in any of these categories? And if the answer makes sense, then: catch up in those areas and reask the question. From my side of the fence, I can't help feeling like there is a basic prejudice among my "guild" toward *anything* that is presented as "the best" - no matter how much the claim can be backed up. And I am personally embarassed by that. Thanks for letting me rant ;-) --- James Squire Send my Spam to mailto:[log in to unmask] MDA^H^H^HBoeing St. Louis http://www.boeing.com --------------------------------------------------------------------------- Now that VMS is on the way out, it tips its cap to Unix by implementing the PIPE command. Talk about locking the barn door after the horse has gotten away... Opinions expressed here are my own and NOT my company's --------------------------------------------------------------------------- "Mollari, what did he say...really." 'He said...that we are both damned.' "Well, it's a small enough price to pay for immortality." -- Refa and Londo, "The Coming of Shadows"