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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d89b08801f2aacae X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-26 11:00:39 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!mango.news.easynet.net!easynet-melon!easynet.net!nnxp1.twtelecom.net!news-east.rr.com!chnws02.ne.ipsvc.net!cyclone.ne.ipsvc.net!24.128.8.70!typhoon.ne.ipsvc.net.POSTED!not-for-mail Message-ID: <3CF1231F.6000609@attbi.com> From: "Robert I. Eachus" Organization: Eachus Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Is strong typing worth the cost? References: <4519e058.0204290722.2189008@posting.google.com> <3CCE8523.6F2E721C@earthlink.net> <3CCEB246.9090009@worldnet.att.net> <3CCFFB7F.B8080F7A@despammed.com> <3CD1608B.A6336379@despammed.com> <3CD176D5.31892591@otelco.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 26 May 2002 17:56:24 GMT NNTP-Posting-Host: 24.61.239.24 X-Complaints-To: abuse@attbi.com X-Trace: typhoon.ne.ipsvc.net 1022435784 24.61.239.24 (Sun, 26 May 2002 13:56:24 EDT) NNTP-Posting-Date: Sun, 26 May 2002 13:56:24 EDT Xref: archiver1.google.com comp.lang.ada:24836 Date: 2002-05-26T17:56:24+00:00 List-Id: Larry Hazel wrote: > Wes - It may have been SAIC. We converted a pilot training simulator from > assembly language to Fortran 77. The company funded an R&D project to convert > the Fortran to Ada. It was quite successful, and found some errors in the > Fortran. I didn't ever see a report on the results but I'm sure there was one. At Honeywell SSD, we converted a (fielded as part of an OS) module from Fortran to Ada 83. The module was mature, but had a number of closed bug reports against it. The process of converting the module discovered several errors in the FORTRAN code. The Ada code ran slower than the original code, but much faster than the corrected/debugged Fortran code. Does that say that coding in Ada found lots of bugs that were not found by the original implementors? (No, some were clearly introduced by other bug fixes.) Does that say that an Ada implementation was less likely to have bugs than a Fortran implementation? (No, there could have been other problems that would not have been noticed in a pure Ada implementation that were not a problem in Fortran or were discovered and fixed during the Fortran implementation.) So what did the study really tell us? That strong typing and subtypes were more than free in Ada, they resulted in tighter, faster machine code. I think Intermetrics had a similar result they presented in a conference. (SIGPLAN 84?) The constraint checking optimizations resulted in about 2% smaller code than with constraint checking turned off. There were enough similar results about the same time than it has become accepted wisdom in the Ada community. Now apparently the question is being asked differently, can you show a development cost savings instead of a code efficiency benefit? What I guess I, and a lot of other here feel is that there is no question there worth asking. Comparing the cost of developing an incorrect version of a program to the cost of developing a correct version is meaningless. And all Ada programmers know from personal experience that strong typing finds bugs in our code at compile time that would be much more difficult to find using the debugger. In fact, there is a very good clue that has been intertwined with this discussion... C programmers will compile their code with debugging options enabled, then run it first via the debugger. Ada programmers tend to compile with debug options turned off, and personally I have never used the debugger that comes with GNAT. (I did use the Verdix debugger a few times though.) In my personal experience, I make very few coding errors that are not caught by the compiler, and many of these are output formatting errors. When I do need to debug something, it is actually the algorithm that I am debugging/testing, and test cases plus occasional embedded print statements are IMHO the best tool for that.