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,60fc398daa7dd9cf X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: KSLOC estimates Ada vs C++ Date: 1999/05/28 Message-ID: <374EDD04.D7603EEA@pwfl.com>#1/1 X-Deja-AN: 483199827 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <374DCB87.6EE9BE49@lmco.com> 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-05-28T00:00:00+00:00 List-Id: Raymond Calande wrote: > > Has anyone ever seen a reference in which a comparison is done that > shows the relative size in KSLOC for Ada versus C++ for the equivalent > program? > TIA After having been involved with software metrics for the last ten years, I'd advise that this is a hopelessly meaningless comparison. Even attempting to compare two programs written in the same language, but solving different problems is difficult and loaded with land mines. Obviously, there are going to be problems which are more easily and naturally expressed in Ada which will take fewer slocs than an equivalent C++ program. The converse also being true. If you are looking for a metric on efficiency or cost or almost anything else, I'd suggest trying something else. It never hurts to create some benchmarks of applications that are "typical" for your problem domain and seeing how a quality implementation in either language fares. But you have to be careful that you aren't misleading yourself or testing the effects of one specific implementation. Its a sticky problem. It would be nice if we were comparing blivet-stamping machines where there is going to be a clear winner based on volume, but we never build the same thing twice so it's a lot more complicated problem. MDC -- 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.*** Visit my web page at: http://www.flipag.net/mcondic