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: f891f,9d9325e2ee8461aa X-Google-Attributes: gidf891f,public X-Google-Thread: f43e6,deda19a53429e1c,start X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,53ac8da1f34d53c4 X-Google-Attributes: gid103376,public X-Google-Thread: 10a1dc,deda19a53429e1c,start X-Google-Attributes: gid10a1dc,public X-Google-Thread: 10204d,960b26935b9a4a0c X-Google-Attributes: gid10204d,public X-Google-Thread: 1014db,deda19a53429e1c,start X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 1995-01-24 10:16:31 PST Path: pad-thai.cam.ov.com!bloom-beacon.mit.edu!panix!news.mathworks.com!udel!gatech!swrinde!news.uh.edu!uuneo.neosoft.com!Starbase.NeoSoft.COM!not-for-mail From: claird@Starbase.NeoSoft.COM (Cameron Laird) Newsgroups: comp.lang.misc,comp.software.international,comp.lang.ada,comp.software-eng,sci.op-research,comp.lang.c Subject: Anticipatory proxies for disaster (was: Gurus - which lang. for this task?) Followup-To: comp.software-eng,sci.op-research Date: 24 Jan 1995 11:32:15 -0600 Organization: NeoSoft Internet Services +1 713 684 5969 Message-ID: <3g3div$jrm@Starbase.NeoSoft.COM> References: <1995Jan12.143131.2083@midway.uchicago.edu> <3fuskb$hae@Starbase.NeoSoft.COM> <3g0rc9$o4j@Starbase.NeoSoft.COM> NNTP-Posting-Host: starbase.neosoft.com Xref: pad-thai.cam.ov.com comp.lang.misc:6930 comp.software.international:1384 comp.lang.ada:14620 comp.software-eng:16672 sci.op-research:2641 comp.lang.c:58830 Date: 1995-01-24T11:32:15-06:00 List-Id: In article , Robert I. Eachus reported on professional experience of his that I find so interesting I urged him to cross-post it to comp.software-eng. He has given me permission to do so. He wrote: . . . > As one of those who fought taking this "feature" out of the >language, I feel duty bound to answer this. At MITRE we found that >whenever an Ada project start slipping due to "long link times," the >problem was always traceable to major design flaws that would prevent >completion of the project. (Since MITRE's main job is acting as a >technical advisor to the DoD on procurements, we get to see a lot of >projects in trouble.) In every case, where fixing things was possible >(technically and otherwise), a few weeks spent restructuring the >design brought the schedule under control. In particular not only did >global recompiles drop from days to hours, they usually also went back >to once per major build, and the programmers spent a lot less time >fighting forest fires. > > So, if your Ada project has unacceptably long link times, C or >Fortran is not the answer--in cases where this type of code switch was >seriously attempted, the same design changes were needed. The answer >is to find out why every compilation needs to with in (tranitively) >several hundred library units. > > On one project we found a unit that was "withed" by over 600 >units, and had over a hundred with clauses of its own. Argh! . . . In his letter to me, he also explained: > You can quote me there if you like. This was the perfect example >of an operations research result. (It may take heavy duty statistical >analysis to reach the conclusion, but it is obvious in hindsight.) > > In this case what we found was that, in C, poor designs break when >the poor sod trying to maintain the makefile can't cope. In Ada, >since all that is automated/enforced you can get a lot more complex >before things fall apart, but the link times start growing >exponentially just before they do. (Fortunately in the Ada case the >break often occurs earlier in the project timeline. During detailed >design if the project is using a design method with executable >specifications.) . . . Follow-ups to c.s-e -- Cameron Laird ftp://ftp.neosoft.com/pub/users/claird/home.html claird@Neosoft.com +1 713 267 7966 claird@litwin.com +1 713 996 8546