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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!newsfeed0.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: comp.lang.ada Subject: Re: Heartbleed Date: Sat, 12 Apr 2014 21:15:17 +0200 Organization: Informatimago Message-ID: <87eh124awq.fsf@kuiper.lan.informatimago.com> References: <1ljwj8f.1wqbhvuabsdw1N%csampson@inetworld.net> <51c7d6d4-e3be-44d5-a4ce-f7e875345588@googlegroups.com> <%J32v.70539$kp1.45343@fx14.iad> <87mwfq4vvj.fsf@kuiper.lan.informatimago.com> Mime-Version: 1.0 Content-Type: text/plain X-Trace: individual.net zSzatzxVFWf+Z7ybUfFeOArNS9pWL6Jb6hzIOKy6N4ofhaIVOi Cancel-Lock: sha1:MzgzZTBiNzJjMGYxNDEyODJhYjc5YzQ4ZGY1Nzc0YmJmNDQ3ZjJkYg== sha1:/tiUmMxN8pY8KkYe4+2S58a9SS8= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Xref: news.eternal-september.org comp.lang.ada:19276 Date: 2014-04-12T21:15:17+02:00 List-Id: Simon Wright writes: > "Pascal J. Bourguignon" writes: > >> But strongly late dynamically typed programming languages are probably >> better for mission critical systems, since they can adapt dynamically >> the type of the values at run-time, instead of crashing. > > If the system designers have thought about what to do under such > circumstances so that the system can carry on, OK, > > If not, the system is operating outside its design envelope, which I > think is equivalent to the Ada "erroneous behaviour; so you don't know > _what_ it will do, and the best response is probably to fall back to a > pre-planned recovery mode. Or, as you say, to crash; which has at least > the virtue, during development, of making it obvious that there's a > problem to be fixed. The Ariane 5 and Mars Climate Orbiter are proof that this is not the right methodology. Those systems were specified, developed with crashes and erroneous behaviour during development, and all bugs were obvious (to the point of making big explosions). Oops, too late! There are life-or-death systems that needs to continue running, even in a degrated mode, whatever happens, whatever bug they may still contain once deployed. Statically checked, variable-typed languages aren't up to the job for those systems. There will always be bugs remaining, even in tested and more importantly, even in proven software! Cf. for example, the Deep Space 1 RAX software, written in Lisp, and proven! Despite the proof, a bug remained. If it had been a statically checked programming language, it would have meant a terminal dead-lock or a crash (what else to do with a static language when we reach a state that has been proved impossible?). But since it was a dynamic programming language, (with very late binding, including a on-board compiler), it was debugged and patched remotely, as a last ressort solution. -- __Pascal Bourguignon__ http://www.informatimago.com/ "Le mercure monte ? C'est le moment d'acheter !"