From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!rsd From: rsd@sei.cmu.edu (Richard S D'Ippolito) Newsgroups: comp.lang.ada Subject: Re: Reasons for dropping Ada Message-ID: <6175@ae.sei.cmu.edu> Date: 20 Feb 90 21:04:02 GMT References: <19409@grebyn.com> Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito) Organization: Software Engineering Institute, Pittsburgh, PA List-Id: In article <19409@grebyn.com> ted@grebyn.com (Ted Holden) writes: >And then, there's the Ada/Software-Engineering problem; if it isn't >grandiose, it's not worth thinking about, much less doing. Not that >there aren't grandiose success stories, such as UNIX or WordPerfect, >around in the world. But wordPerfect started out as a simple little >editor program written in PC assembler and added features every six >months or so until it finally EVOLVED into something grandiose. If the >same program were to be "designed" and written under DOD specs, then >they would just be getting version 1.0 out the door now, after seven >years of design, followed by two years of coding, at the end of which >the entire package would be magically required to function properly, >just like the Airbus control system, the Space Telescope, Stanfins, WIS, >and all of your other great successes do. You have cited UNIX and WordPerfect before as "success" stories, and had been asked several months ago by another reader to provide supporting data. I have not seen your reply. Have you made it? I would suggest that the number of users of a product is not a direct measure of quality or of engineering prowess. (Horses were widespread until displaced by autos.) If you haven't cited numbers to demonstrate productivity and quality of those products, will you please do so now? I will accept either number of source lines of code per person-month and number of errors per KLOC, or other results based on your own definitions. I understand that a version of WordPerfect was rewritten from scratch in C. This might be a good one for you to comment on as to the amount of design, implementation, and integration times spent and how close the company came to meeting the targeted release date. I have a UNIX system here that still has numerous errors, some of which are listed rather triumphantly, if not belligerently in the manuals. Let me quote a sample of them: BBEMACS(1) I tinker too much, so occasionally I mess up and it don't work no good. But then I fix it, hooray. DAB(!1) There is a mysterious bug causing occasional core dumps... ...just send mail to the author. FILE(1) It often makes mistakes. JOBS(3J) There is no excuse for the "getwd" routine to be in the jobs library. There is even less reason for this routine not to have been documented by the author(s) at Berkeley. PARSEDATE(3) The grammar is incomplete and always will be. PUTC(3) Errors can occur long after the call to 'putc'. SCANF(3S) The success of literal matches and suppressed assignments is not directly determinable. SIN(3M) The value of 'tan' for arguments greater than about 2**31 is garbage. CTAGS(1) ...if you have two Pascal procedures in different blocks with the same name, you lose. EMACS(1) Not bloody likely. TC(1) The aspect ratio option is unbelievable. UNITS(1) Don't base your financial plans on the currency conversions. Now, your system may have different texts for some of these, but I have several sets of manuals spanning years which contain some of the same texts (DEC substitutes the word 'unreliable' for the original 'garbage'). As I said, these kinds of messages aren't universal, but there enough of them spanning a large enough sample of years and programmers to cause me to question the kind of attitude of the folks you continually hold up as model programmers. There is a more fundamental question, however, that we can save for another time, having to do with the suitability of the current software models implied by the systems and languages you support for large-scale projects. It makes no sense to touch it when there is such an obvious disconnect. Rich -- Hitting baseballs and writing software are two professions where you can become a millionare with a 75% performance failure rate. rsd@sei.cmu.edu ------------------------------------------------------------------------