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: 11232c,59ec73856b699922 X-Google-Attributes: gid11232c,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,899fc98b2883af4a X-Google-Attributes: gidf43e6,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 2003-05-16 05:25:15 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: mcq95@earthlink.net (Marc A. Criley) Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,misc.misc,comp.software-eng Subject: Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)) Date: 16 May 2003 05:25:14 -0700 Organization: http://groups.google.com/ Message-ID: <254c16a.0305160425.3bb89749@posting.google.com> References: <9fa75d42.0304230424.10612b1a@posting.google.com> <9fa75d42.0305091549.48b9c5d9@posting.google.com> <7507f79d.0305121629.5b8b7369@posting.google.com> <9fa75d42.0305130543.60381450@posting.google.com> <254c16a.0305140549.3a87281b@posting.google.com> <9fa75d42.0305141747.5680c577@posting.google.com> NNTP-Posting-Host: 12.158.183.115 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1053087915 11939 127.0.0.1 (16 May 2003 12:25:15 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 16 May 2003 12:25:15 GMT Xref: archiver1.google.com comp.lang.java.advocacy:63900 comp.object:63531 comp.lang.ada:37380 misc.misc:14220 comp.software-eng:19223 Date: 2003-05-16T12:25:15+00:00 List-Id: "soft-eng" wrote in message news:9fa75d42.0305141747.5680c577@posting.google.com... > I don't agree that Ada is likely to be particularly useful > for catching errors in a professional environment -- say 2-3% > of the actual errors at best. If it's catching more than > that, I don't see how you can have good people. > > But good people can certainly make projects succeed using > many kinds of tools, including Ada. Now waitaminnit. First we read a recommendation for software development success that consists of "1) Hire good people, and give them the tools they need." Since that was the extent of the advice, presumably that's the foundation for success. And given the nature of this debate, it is being argued that the Ada programming language is not to be considered an inherently good tool that aids success (from a purely technical perspective). And that, in contrast, one would be hard-pressed to achieve success if one believes that "2) [...] You just need to give them a quality solution, and quality will follow. Just tell them what to do and make sure they do it. [...] For instance, a militaristic language that will catch all their errors and solve the problem of human fallibility. Or a methodology that will make quality flow out their ears. Typical command-and-conquer stuff is "now everybody will write a spec in this here format before starting a new module." [Excisions done with care.] But, but, we did achieve success! We had a quality architecture and design that took advantage of Ada's technical strengths, the staff was a set of good, journeyman programmers--no gurus, except for one exceptional young woman--with anywhere from a few month's to 10 years experience with Ada, the design was in keeping with a quality methodology (OMT), and development followed a rigorous "command-and-conquer" process for all defect identification/analysis/resolution/rework/retest/rebaselining. And yes, it was made certain that everyone rigorously followed it. Reread what the outcome was: >>mcq95: >> The end result of the project was a serious weapon command and control >> system that came in on schedule, on budget, with no late nights or >> weekends required of either the development or test staff, and the >> lowest number of unresolved defects in any production release of the >> system--1 of severity 4 (out of 5, where 1 is critical, and 5 is >> considered a nice-to-have). We did all that stuff that you claim is supposed to work against project success, yet the project succeeded nonetheless, and rather painlessly at that. > The only thing is they might privately grumble more, and may > often have to get C/C++ libraries written by outside vendors > or themselves. (Usually there are excuses - We could > have done it all in Ada, except for this and that... Now where does that come from? "Grumbling?" "Excuses?" About going home and having dinner with the family each night, and having one's weekend to themselves? Excuses for what? For the system having the lowest defect rate of any production release and it steadily improving with each passing day? Okay--it was Ada's fault! There still seems to be this complete ignorance of the benefits of Ada and strong typing: Strong typing doesn't just "catch errors" (but for the sake of argument I'll allow the low figure of 2-3% that you propose). Some such errors you don't even really notice as errors. For instance, if I accidentally swap Latitude and Longitude in a procedure call, the compiler barfs, I fix it, and move on. Well, that one compilation error just saved a lot of time, since that error probably wouldn't get noticed until an executable gets into some sort of testing, whether unit or system testing. But again, the real benefit of error prevention comes not from those errors that are caught, but from those that _never_ occur! Iterating over an array: for Eng in Engagements'Range loop ... end loop; There will _never_ be an array indexing error. Every reference to Some_Type'Last or Some_Array'Length will _always_ be valid, they will never, ever exceed the valid range. When strong typing is properly employed, a variable will never take on an invalid value--and if an attempt is made to do that, such as by assigning to a subtype with a more constrained range, an exception is immediately raised (one of those 2-3% of errors). It's not that Ada prevents all errors from occurring (that's an absurd claim that anti-Ada zealots repeatedly and disingenuously try to attribute to Ada advocates), but it a priori does in fact prevent certain classes of errors from occurring, and immediately catches other classes of errors when they occur. And these errors continue to be put into code every day by programmers throughout the ability continuum: idiot, competent, and guru. It's no harder to code taking advantage of strong typing than not, and thereby avoid whole classes of errors--and I'd argue it takes more effort to fight it, or to manually code the equivalent capability in more weakly typed languages. Given the effort it saves, why not code in Ada? Marc A. Criley