Re: Mathematica and Lisp
- To: mathgroup at smc.vnet.net
- Subject: [mg129802] Re: Mathematica and Lisp
- From: John Doty <noqsiaerospace at gmail.com>
- Date: Fri, 15 Feb 2013 01:57:08 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: l-mathgroup@wolfram.com
- Delivered-to: mathgroup-newout@smc.vnet.net
- Delivered-to: mathgroup-newsend@smc.vnet.net
- References: <kcqkv4$lq5$1@smc.vnet.net> <kct7fj$sgo$1@smc.vnet.net>
On Friday, February 8, 2013 10:43:19 PM UTC-7, Richard Fateman wrote: > Regarding the Therac-25 (not theravac); > > you can read about it on Wikipedia. > > http://en.wikipedia.org/wiki/Therac-25 > > and also look at the links, especially Nancy Leveson's report > > http://sunnyday.mit.edu/papers/therac.pdf > > especiall page 7, top. > > which I think is the most significant. > > > > As I recall, the operator editing the display screen used > > carriage returns etc to go between fields and thought that > > the actual settings were reflected by what appeared on the screen. > > This was not the case. > > > > There are other factors too. Lack of hardware interlocks, certainly > > a systems design error, also > > meaningless error messages (how could THAT happen?) > > hard to debug programming language (assembler). There are always bugs in non-trivial software. There are always layers of misunderstanding: 1. The engineers (hardware and software) never fully understand the application, and are usually too stubborn to admit this. 2. The programmers never fully understand the hardware, and are usually too stubborn to admit this. 3. The operators never fully understand the machine, and are usually too stubborn to admit this. Hardware is not perfectly reliable, especially in radiology departments where there's much EMI and possibly other problems like stray neutrons (I know from experience that unhardened microcontrollers misbehave near the MGH cyclotron in Boston, even in "shielded" areas). Operators are often distracted, tired, and pressured. And misspelling of silly made-up words is common, too ;-) One must therefore assume that if the hardware can be put into a fatal configuration, it will be at some point. When it actually happens, the retrospective details of how it happened are misleading. The fundamental engineering issue is that one must design so that the ordinary, routine failures do not cascade to fatality. By removing the hardware interlock, the Therac engineers had designed the system to fail.