<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 29 Apr 2014, at 09:12, Alexander Schreiber <<a href="mailto:als@thangorodrim.de">als@thangorodrim.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Tue, Apr 29, 2014 at 12:40:09AM +0200, Pascal J. Bourguignon wrote:<br></div></blockquote><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite"> * Programmed in Common Lisp, either the fixnum in the Ariane 5 would have<br> been converted into a bignum, or an condition would have been<br> signaled, which could have been handled. This would have taken<br> time, which could perhaps have "exploded" the real time constraints,<br> but it is better to control your rocket slughishly than not to<br> control it at all.<br></blockquote><br>That was not the real problem. The root cause was the design assumption that<br>overflowing value was _physically_ limited, i.e. during normal operation<br>it would have been impossible to overflow and an overflow would in fact have<br>signaled some serious problems bad enough to abort. While this held true in<br>Ariane 4, it no longer was true in the more powerful Ariane 5.<br><br>Your "solution" would have papered over the flawed design assumptions, which<br>is _not_ the same is fixing them.<br></div></blockquote><div><br></div><div>You’re forgetting we’re talking about embedded programs with real-time processes. </div><div>You don’t have the time to stop everything and “debug” the design. </div><div>You have to control a rocket and avoid it crashing!</div><div><br></div><div>That’s the reason I’ve not mentionned RAX yet: the situation was quite different, </div><div>since they had the time to perform remote debugging, over several days.</div><div><br></div><br><blockquote type="cite"><div></div></blockquote><br><br><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"> * Programmed in Common Lisp, instead of using raw numbers of physical<br><blockquote type="cite"> magnitudes, you'd use objects such as:<span class="Apple-converted-space"> </span><br><br> (+ #<kilometer/hour 5.42> #<foot/fortnight 12857953.0> )<br> --> #<meter/second 4.7455556><br><br> and Mars Climate Orbiter wouldn't have crashed.<br></blockquote><br>This is ridiculous. If you end up mixing measurement systems (such as metric<br>and imperial) in the same project, you are _already_ doing it horribly wrong.<br></div></blockquote><div><br></div>It wasn’t in the same project. The data was actually sent from a remote Earth station. </div><div>So this is even worse than not using magnitude with units inside the process, it was a </div><div>serialization/deserialization error. But notice how Lisp prints out the speeds above! </div><div>It writes the units along with the values!</div><div><br></div><div>Now, of course it’s not a programming language question. We already determined that, </div><div>when noting that neither the ANSI Common Lisp nor the ANSI C standard imposes </div><div>bound checking, but that C programmers don’t code bound checkings, and C implementers, </div><div>being C programmers, implement compilers that don’t do bound checking, while the </div><div>inverse is true of Common Lisp programmers.</div><div><br></div><div>This is always the same thing: “statically typed” proponents want to separate the checks </div><div>from the code, performing (or not) the checks during design/proof/compilation, while </div><div>“dynamically typed” proponents keep the checks inside the code, making the compiler </div><div>and system generate and perform all the typing, bounds, etc checks at run-time. </div><div>So when a C guy (any statically typed guy) sends data, he expects that the type and</div><div>bounds of the data are know (before hand, by both parties). But when a Lisp guy (any </div><div>dynamically typed guy) sends data, he sends it in a syntactic form that explicitely </div><div>types it, and the data is parsed, validated, bound checked and typed according to </div><div>the transmitted syntax on the receiving end.</div><div><br></div><div><br></div><div>Of course, generating C code doesn’t mean that you can’t design your system in a </div><div>"dynamically typed” spirit. But this is not the natural noosphere of the C ecosystem.</div><div><br></div><div><br></div><div><br></div><div><br><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">The design fault was mixing measurement systems, which one should _never_ do<br>on pain of embarassing failure. Papering over this design screwup with a<br>language environment that _supports_ this (instead of screaming bloody<br>murder at such nonsense) doesn't really help here.<br></div></blockquote><div><br></div><div><br></div>Again, we are talking about an embedded program, in a real time system, where you </div><div>have only seconds of burn stage on re-entry, and where you DON’T HAVE THE TIME </div><div>to detect, debug, come back to the design board, compile and upload a new version!</div><div><br></div><div>The software that uploaded the untagged, without units, bit field *data*, instead of </div><div>some meaningful *information*, hadn’t even been completed before the orbiter was </div><div>in space! It wasn’t developed by the same team, and wasn’t compiled into the same </div><div>executable.</div><div><br></div><div>Nonetheless, here a lisper would have sent *information* in a sexp, and dynamic </div><div>checks and conversions would have been done.</div><div><br></div><div>If you will, the design would have been different in the first place!</div><div><br></div><div><br><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite"> * Programmed in Common Lisp, the Therac-5 bug wouldn't have occured:<br><br> "The defect was as follows: a one-byte counter in a testing<br> routine frequently overflowed; if an operator provided manual<br> input to the machine at the precise moment that this counter<br> overflowed, the interlock would fail."<br></blockquote><br>But why did the counter overflow in the first place? Was it simply programmer<br>oversight that too small a datatype was used or was this actually an error<br>that just didn't have noticeable consequences most of the times? If the<br>later, then again, papering over it with a never overflowing counter is<br>not a fix.<br></div></blockquote><div><br></div><div>But it if was a problem, it *would* eventually reach a bound check, and signal </div><div>a condition, thus stopping the process of irradiating and killing people.</div><div><br></div><div>Remember: a Lisp program (any "dynamically typed” program) is FULL of checks!</div><div><br></div><div><br></div><br><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite"> since again, incrementing a counter doesn't fucking overflow in<br> lisp!<br><br> * Programmed in Common Lisp, heartbleed wouldn't have occured, because<br> lisp implementors provide array bound checks, and lisp programmers<br> are conscious enough to run always with (safety 3), as previously<br> discussed in this thread.<br></blockquote><br>Hehe, "conscious enough to run always with (safety 3)". Riiiiight. And nobody<br>was ever tempted to trade a little runtime safety for speed, correct?<br></div></blockquote><div><br></div>Those are C programmers. You won’t find any other safety that 3 in my code. </div><div>You should not find any other safety than 3 in mission critical code, much less</div><div>in life threatening code.</div><div><br></div><div><br><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">As for heartbleed: arguably, the RFC that the broken code implemented<br>shouldn't have existed in the first place.<br><br><blockquote type="cite">What I'm saying is that there's a mind set out-there, of using modular<br>arithmetic to approximate arithmetic blindly. Until you will be able to<br>pay $1.29 for 3 kg of apples @ $2.99, people should not program with<br>modular arithmetic!<br></blockquote><br>Well, modular arithmetic doesn't go away because one wishes it so. As a<br>developer doing non time critical high level work one might be able to<br>cheerfully ignore it, but the moment one writes sufficiently time critical<br>or low level code one will have to deal with it. Because modular arithmetic<br>is what your CPU is doing - unless you happen to have a CPU at hand that<br>does bignums natively at the register level? No? Funny that.<br></div></blockquote><div><br></div>This might have been true in 1968, when adding a bit of memory added 50 gr. of payload!</div><div><br></div><div>Nowadays, there’s no excuse.</div><div><br></div><div><br><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite"><blockquote type="cite">And if the flight safety of an aircraft depended upon the current<br>Lisp version of Ironclad's impenetrability, we would be in trouble.<br></blockquote><br>This is another question, that of the resources invested in a software<br>ecosystem, and that of programming language mind share. Why the<br>cryptographists don't write their libraries in Common Lisp and choose to<br>produce piles of C instead?<br></blockquote><br>Usefulness. If I write a library in C, pretty much everything that runs on<br>Unix can link to it (if need be, via FFI and friends) and use it. If I write<br>a library i Common Lisp, then code written in Common Lisp can use it unless<br>people are willing to do some interesting contortions (such wrapping it in<br>an RPC server).<br></div></blockquote><div><br></div>Anything running on unix can link to libecl.so (which is ironically a CL</div><div> implementation using gcc, but we can assume it’s a temporary solution).</div><div><br></div><div><br><blockquote type="cite"><div style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Exercise for the interested: write a library in Common Lisp that does, say,<br>some random data frobnication and try to use it from: C, Python, Perl, C++<br>_without_ writing new interface infrastructure.<br></div></blockquote><div><br></div>But the point is to eliminate code written in C, Perl, C++! So your exercise is academic.</div><div><br></div><div><div><div>— </div><div>__Pascal Bourguignon__</div><div><br></div><br class="Apple-interchange-newline"></div><div><br class="webkit-block-placeholder"></div></div></body></html>