<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 16, 2014 at 10:11 PM, Miles Fidelman <span dir="ltr"><<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@meetinghouse.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good point.  "Let it crash" does take on a whole different meaning when dealing with aircraft and such.</blockquote>

</div><br>This is a different point as well! You have two axis:</div><div class="gmail_extra"><br></div><div class="gmail_extra">* soft vs hard realtime. Some systems require hard realtime and then your tools are limited to languages where you have explicit memory control, enabling you to avoid allocating memory and triggering garbage collection. In soft realtime systems, you have more leeway, and if built the way of the Erlang runtime system, you get really good soft realtime capability.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">* Proactive vs Reactive error handling. The idea of "let it crash" is definitively reactive, whereas static type systems, proofs, model checking, etc are means of proactive error handling.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">My claim however, is that you need "Let it crash" in Aircrafts as well if you want to have a stable aircraft. The model where you blindly attempt to eradicate every error from a program is bound to fail sooner or later. Usually "let it crash" in those situations is implemented in hardware by having multiple redundant systems. But rarely are systems exempt of failure. Even in a highly controlled environment.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><br clear="all"><div><br></div>-- <br>J.
</div></div>