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: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-ArrivalTime: 2003-05-15 21:03:29 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hammer.uoregon.edu!enews.sgi.com!sdd.hp.com!ihnp4.ucsd.edu!news.ucsd.edu!not-for-mail From: Dr Chaos 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)) Followup-To: comp.lang.java.advocacy Date: Fri, 16 May 2003 04:03:24 +0000 (UTC) Organization: Univ of Calif San Diego Message-ID: 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> <3EC3EEFF.4030601@psu.edu> NNTP-Posting-Host: lyapunov.ucsd.edu X-Trace: news1.ucsd.edu 1053057804 8722 132.239.222.85 (16 May 2003 04:03:24 GMT) X-Complaints-To: usenet@news1.ucsd.edu NNTP-Posting-Date: Fri, 16 May 2003 04:03:24 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) Xref: archiver1.google.com comp.lang.java.advocacy:63877 comp.object:63506 comp.lang.ada:37373 comp.software-eng:19217 Date: 2003-05-16T04:03:24+00:00 List-Id: On Thu, 15 May 2003 21:47:00 -0500, John R. Strohm wrote: > X-A-Notice: References line has been trimed due to 512 byte limitation > Abuse-Reports-To: abuse at airmail.net to report improper postings > NNTP-Proxy-Relay: library2.airnews.net > NNTP-Posting-Time: Thu, 15 May 2003 22:01:06 -0500 (CDT) > NNTP-Posting-Host: !Zf<,1k-W@h7L(; (Encoded at Airnews!) > X-Priority: 3 > X-MSMail-Priority: Normal > X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 > > "Robert Spooner" wrote in message > news:3EC3EEFF.4030601@psu.edu... >> The experience drove home to me the truth that you can't just scale up >> what works on a small project and expect it to work just as well on a >> large one. That's why Ada is so useful for programming in the large - it >> gives you the architectural tools you need so that you don't have to >> contend with the software version of a wire wrap board with 14,400 pins. >> The nuclear industry found out that scaling up a 50 megawatt submarine >> propulsion reactor to 500 or 1000 megawatts for power generation didn't >> work so well either. > > Examples to back up that statement? Submarine reactors use quite highly enriched (closer to bomb-grade) uranium. (It would be very very bad if terrorists could steal their core, but generally they are considered pretty damn secure and hard to break into, and unless it is virgin fuel, it will be very radioactive.) Fission reactors rely on the rather remarkable and very fortuitous property of fissioning uranium that two neutrons come out of the nucleus within microseconds, whereas on average a third one comes out of the products over the span of hours. A reactor is designed to be stable to prompt neutrons, in that there is a net exponential decrease of fissions from these on the microsecond timescale, but unstable (when ramping up) or critical (at steady state) when you count the slow neutrons. Neutron loss is a function of absorption by moderators and physical geometry, where free neutrons escape the boundary of the fuel and do not fission any more. As a result a design that is satisfactory in a smaller geometry (submarine) can be very unsatisfactory if you scale everything up, because a large assembly of highly enriched Uranium will go unstable to prompt neutrons. That is definitely Bad. The reactor at Chernobyl went unstable to prompt neutrons. I can see an analogy to programming here. If you use less 'safe' tools, then in a small project you can still be stable where the fixing of one bug or addition of a feature does not cause it to go exponentially unstable. But if you had a big system, the 'free neutron' from a bug fix is more likely to intersect some other part of the system. If it's too big, you are more likely to get an exponentially growing cascade of crap: it went unstable. the point being that differences in "safety" among programming langugaes and systems may be irrelevant and minor in small scale programming---and in people's experience the safety technology is constraining and annoying. But even that small difference may turn out to be the difference between a safe and stable large system and prompt criticality. dogbert says: hey engineers, next time you hear that cliche "getting a critical mass" in a business buzzword setting, drolly mention "oh yes, you must mean prompt criticality". Think "Chernobyl".