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.6 required=5.0 tests=BAYES_05,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e384729507492509 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-30 17:48:56 PST Path: nntp.gmd.de!newsserver.jvnc.net!news.cac.psu.edu!news.pop.psu.edu!psuvax1!uwm.edu!msuinfo!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!sunb.ocs.mq.edu.au!krakatoa!cperrott From: cperrott@krakatoa.mqcs.mq.oz.au (Chris Perrott) Newsgroups: comp.lang.ada Subject: Re: Ada in Australia (was Ada ad in Embedded Systems Programming stinks) Date: 30 Oct 1994 02:41:04 GMT Organization: Macquarie University, Sydney Australia Message-ID: <38v140$sdu@sunb.ocs.mq.edu.au> References: <9410131051.AA29342@eurocontrol.de> <38neq3$9dg@f111.iassf.easams.com.au> <38us16$c0e@godzilla.zeta.org.au> NNTP-Posting-Host: krakatoa.mpce.mq.edu.au Date: 1994-10-30T02:41:04+00:00 List-Id: In article <38us16$c0e@godzilla.zeta.org.au> andrewl@zeta.org.au (Andrew Lees) writes: >bjw@f111.iassf.easams.com.au (Brendan WALKER) writes: > >[snip] > >>It is also worth noting that of three Ada projects you mentioned, I know for >>a fact that at least two of these are in SERIOUS trouble, facing serious >>architectual/design problems and the resulting cost and schedule slip (like 3+ >>years late!!). > >Hmm, > >I suspect that I should not really respond to this, but the implication here Probably right! >(that Ada is involved in any problems these projects may have ) is simply >too wrong to leave alone. > >I am aware of all of these projects, having been involved in one for seven >years, having technically auditted one other, and having close contacts >in the third. > >Where there have been problems, the root causes have been in the management >domain rather than the technical. This is so on both of the projects that Well, yes and no. Ada 83 provides a way to get the address of a procedure, but doen't provide a way to _call_ a procedure using its address. Management decides that the project is to be done in pure Ada, and forbids use of assembly language to call a procedure using its address. >have had some difficulties. On the project that has not had difficulties, >the same applies: the reason for its success has been consistently >excellent management. > >In my direct experience (and despite my own doubts along the way) Ada has been >a good implementation language for large projects. What needs to be understood >is that no language can make up for unresolved management issues. When >management issues start to become solved, projects start to make real progress. > >The design of the Ada language simplifies the management of the software >production process considerably. > >When used well, the visibility >structures of the language enable very rapid understanding to be obtained Are the visibility structures of Ada 83 really any better than those of C++? Doesn't Ada 83 suffer from the lack of a structure larger than a package, something like the new C++ namespace? >of code to which one has had no previous exposure. My role frequently >involves system troubleshooting so I value this aspect of the language >highly. I know of no other language in large scale use that would be >as helpful. (Yes, I have spent many years developing software in 'C'). > >I see Ada as providing significant benefits in the development of large >systems. Having said this, I can see that we are not yet taking proper >advantage of all that can be gained from the language, with better >design processes and attendent reduction in rework having particular Better design methods would help, but watch out for management interpreting 'reduction in rework' to mean 'iterative development is forbidden'. >scope for useful productivity improvements. > >>Brendan Walker > >Andrew Lees. Chris Perrott