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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c6e9700a33963193 X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: The future of Ada Date: 1999/03/11 Message-ID: <36E7E108.246E90BE@pwfl.com>#1/1 X-Deja-AN: 453821627 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <36E690FA.4B9C@sandia.gov> <7c7coa$nvt$4@plug.news.pipex.net> <1999Mar11.080820.1@eisner> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada Date: 1999-03-11T00:00:00+00:00 List-Id: Larry Kilgallen wrote: > > In article <7c7coa$nvt$4@plug.news.pipex.net>, "Nick Roberts" writes: > > > I emphasise the "is not possible" because I know well that a manager will > > not be convinced in the slightest by "is not the best way" or the like, but > > will be convinced by an absolute "it WILL not work". Whether this is > > actually strictly true or not is immaterial (and you must not show it). > > Depending on your organization, an equivalently strong statement to > "it WILL not work" is "it WILL not be delivered on time". > Shooting schedules is probably one of the most persuasive arguments. The case for this is easy to make. Historically, C/C++ spends much more time in integration and debugging because of the unsafe constructs and lack of compile time checks. What is worse is that you can document significantly higher numbers of errors escaping into the field - something that could easily bankrupt a company when the warranty costs skyrocket. Software bugs found in the field once just about put Pitney Bowes out of business. ("If you code it in C++ you're putting the entire business at risk!!!" :-) There are any number of reports on this. One of my favorites was a study done at Lucent Technologies on the nature of the bugs discovered in their large applications. (Wish I still had the URL...) We went through the study informally here to see if we could gain insight into our own bugs. (We have amazingly few, and I have metrics which show it steadily declining since the adoption of Ada & some other tools.) The conclusion we came to was that the overwhelming number of bug types found in Lucent's software _could not happen_ in Ada because of compile time checks. Lucent opted for various programmer training and code review options to eliminate the common errors. They naturally only _reduce_ the errors in a very costly & time consuming manner. It's always cheaper to let the compiler find problems than to try to inspect the problems out of the system after the fact. Actually, I'm pretty amazed that someone would look at a system that is near complete and decide to go back to square one & re-code it in a new language for fear that one day there won't be any programmers who can maintain the system. Re-coding the system in a new language is always something that you can stall off until it becomes essential - which may never happen. So you for sure spend the money today rather than maybe never spend it. Spending it ten years from now is much cheaper because of the time value of money. Pretty bone-headed, if you ask me. ;-) -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** "Software engineers are, in many ways, similar to normal people" -- Scott Adams