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,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 12:20:50 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc01.POSTED!not-for-mail Message-ID: <3EC539FA.1040500@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,comp.software-eng Subject: Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)) References: <9fa75d42.0304230424.10612b1a@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> <3EC3D737.6020509@attbi.com> <9fa75d42.0305160924.2bf76373@posting.google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.62.164.137 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc01 1053112847 24.62.164.137 (Fri, 16 May 2003 19:20:47 GMT) NNTP-Posting-Date: Fri, 16 May 2003 19:20:47 GMT Organization: AT&T Broadband Date: Fri, 16 May 2003 19:20:47 GMT Xref: archiver1.google.com comp.lang.java.advocacy:63945 comp.object:63570 comp.lang.ada:37404 comp.software-eng:19243 Date: 2003-05-16T19:20:47+00:00 List-Id: soft-eng wrote: > Other times are when the bug is very intermittent > and cannot be duplicated and you have to proceed > blindly, based on theories that are sometimes half-baked. We call those Heisenbugs. Converting a Heisenbug to a Bohrbug that you can reproduce is often the first part of fixing the problem. > And then there are cases where you are working > with a crucial part of the system, without fully > understanding its full impact on the rest of the > system. So you fix a bug, and the rest of the > system comes crashing down on you... > > But the truth is the choice of language has little to > do with situations like these. No, no, NO! Sorry. There are two nice software engineering terms coupling and cohesion. Low coupling means that program modules have a low degree of interaction with other modules. Cohesion means that code in one module all deals with the same data construct or constructs. Low coupling and high cohesion are good, and the combination of good software design and Ada allows you to achieve very low coupling and good cohesion. You can't manage this without good software engineering, and you can do bad software engineering in just about any progamming language, including Ada. What Ada allows you to do is accomplish extremely low coupling. For example, assume your design requires several different list structures, including single and double ended queues. In Ada you can have a dozen different queue types in your program library. At each point where a list or queue is needed you instantiate a generic. The generic instantiation is the only coupling between the program and the queue module. There is no coupling between the queue module and the program. This combination of data hiding, data abstraction, and modularization is what makes Ada so wonderful for programming in the large. In a good Ada design, it is normal for program modifications, whether they are bug fixes or adapting the system to new requirements to only affect one module. I can't begin to count the number of times when something which would be a month's work if we hadn't used Ada turned out to be a "trivial fix" in Ada. I remember one time when during the system acceptance testing for a 150,000 LOC project, the users noticed a problem with the user interface (which worked as specified). At the end of the first day, the program manager was tasked to find out the cost of making the change, which would require a change to several major data structures. (Basically it provided a common mechanism for the users to back out of any data entry transaction with no updates occuring, rather than knowing how often to hit the escape key.) By lunch the next day, he had a cost estimate, and a (one page) diff from re-running all the test scripts. Turned out that the change belonged in a component which was part of all the data types, and the implementation was private to one package. Total LOC changes? Nine, including three comment lines. ;-) > Sorry, there is NO magic bullet for such things. > I strongly doubt stories where the choice > of a new language turned all coders into > highly disciplined professionals, just like > I doubt array-bounds-checking is the most > useful invention in programming languages ever, > before which everybody was just sloppily writing > outside their arrays all the time as a matter of habit. Ada is not a magic bullet. What it does allow is that if you have a good process for creating a workable overall software design structure, then Ada modularization rules match the project structure. As long as the implementor of a module stays within the lines, he can't add coupling to the system during development. To go back to the original discussion, once the software design is finished, any change which would increase coupling comes with very serious warning flags attached. Since there is almost never a reason to make one of those changes, a project manager can keep a hammer in his office to use on anyone who proposes such a change. (A foam rubber hammer, of course, unless you have some programmers who are incapable of learning. Actaully, this is a matter of personal preference. At Stratus I kept a plastic Whiffleball bat in my umbrella stand, and it came out and was on my desk or in my hand whenever someone wanted to change a global data structure, in a way that was visible to other modules. ;-) Sometimes finding a way to make the change without adding coupling is tough. But in the long run it was worth it to take several hours of time to find a better way.