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 X-Received: by 10.182.28.102 with SMTP id a6mr2955982obh.44.1402067585176; Fri, 06 Jun 2014 08:13:05 -0700 (PDT) X-Received: by 10.182.21.99 with SMTP id u3mr25126obe.10.1402067585015; Fri, 06 Jun 2014 08:13:05 -0700 (PDT) Path: backlog3.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!c1no23857808igq.0!news-out.google.com!qf4ni19593igc.0!nntp.google.com!c1no23857807igq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 6 Jun 2014 08:13:04 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.252.147.203; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 71.252.147.203 References: <3bf7907b-2265-4314-a693-74792df531d1@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <51e9fd4f-e676-4d2f-9e21-1c782d71092e@googlegroups.com> Subject: Re: a new language, designed for safety ! From: "Dan'l Miller" Injection-Date: Fri, 06 Jun 2014 15:13:05 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 8504 X-Received-Body-CRC: 1072747087 Xref: number.nntp.dca.giganews.com comp.lang.ada:186764 Date: 2014-06-06T08:13:04-07:00 List-Id: On Thursday, June 5, 2014 5:40:24 PM UTC-5, Robert A Duff wrote: > "Nasser M. Abbasi" writes:=20 > > On 6/4/2014 2:43 PM, Robert A Duff wrote: > > >> But I wouldn't call it "unsafe" if you get a run-time error. I am glad that you are not working for the FAA or NTSB regarding what is an= d is not a safety-critical software system. Currently in the popular press, General Motors ignition-switch recall has s= trong resemblance to Mr. Duff's picayune excessively-narrow definition of s= afety of a system. For over a decade, GM fervently held the perfectly-fact= ually-correct position that if the ignition switch has dangling from it not= hing other than the keys that GM issued plus one key ring, then the spring = in the ignition switch was of sufficient resistance to assure that gravity = does not turn the ignition switch to a different position (e.g., the off-po= sition, which could cause sudden loss of power-steering and power-brakes, i= n turn playing a nontrivial role in a wreck, in part by surprising the driv= er into a panic). Mr. Duff and GM adopt an excessively narrow definition o= f safety of a system here in their respective lines of reasoning. GM's off= icial position was in effect: it is not our fault if a driver of a vehicle= put more keys on their keyring than what GM issued at the time of initial = sale and those nonGM keys placed more load on the ignition-switch's spring = than what GM minimally designed that spring to withstand. The federal gove= rnment correctly lambasted such an excessively narrow definition of safety = of a system, because of a failure-mode caused by a commonplace scenario tha= t could have easily been averted at build-time of the system. The question= of safety does not hinge on academic purity of an ideology, but rather on = how affordably & practically preventable at build-time a commonplace failur= e-mode scenario is. > > This depends if the run-time error could have been avoided in > > the first place had the compiler been able to detect the > > problem at compile time or not? >=20 > No, the meaning of "safe" and "unsafe" doesn't depend on that. Actually in general, it does. Please see the explanation below at the end = of this posting. > > With these dynamics languages (Julia, swift, Matlab, etc...), > > many errors will show up at run-time, since there is no > > static time compiler with a rich language semantics that > > allows the compiler to do more analysis and find more errors > > even before the program is run. >=20 > Quite true, but not relevant to my point about the word "unsafe". > As I said, to me, "unsafe" (applied to programming language features) > means "misuse of this feature can cause unpredictable behavior". During an accident investigation, the NTSB and FAA would reject your irrele= vance assertion, as explained below at the end of this posting. > Run-time errors are bad enough, but unpredictable behavior is far > worse; it's useful to have a word to describe that distinction. >=20 > > Even though some dynamic languages will not let one at run > > time mix apples and oranges, and will give run-time error, > > I'd rather know at compile time that I am not mixing apples > > with oranges. That is much more safe. So would I, Nasser. I thoroughly reject the narrowness of Mr. Duff's picay= une definition of software safety and of what is or is not a facilitator of= a safety-critical software system. > No, it is "better", perhaps, but not "safer". By my definition, > "safe" and "unsafe" are absolutes; a feature either can or cannot cause > unpredictable behavior. There's no "safer" and "less safe". Mr. Duff, here I agree with you, but not in the way that you intend: Mr. D= uff, your unwisely narrow definition of safety of a software system is not = less safe, it is full-fledged unsafe. Mr. Duff, your own definition of "sa= fety" of software in a safety-critical software system is itself unsafe, be= cause usage of your definition could itself directly cause bodily injury or= loss of life if it were utilized in a safety-critical system. How? By lu= lling people into believing that all of the state-of-the-art assurances & p= recautions have been taken to eliminate whole categories of failure of soft= ware. And when I say state of the art, I mean here 1970s-era technology on= which Ada & C++ & only a very few other OO languages are based: compile-t= ime assurance that an invoked method actually was implemented, instead of S= mallTalk's, Objective-C's, and Swift's unsafe cavalierness in this regard. = To not have compile-time assurance that an invoked OO method actually was = implemented on some rarely-executed branch of code is taking the software i= ndustry & knowledgebase back as much as 4 decades in direction of primitive= ignorance of the solutions to that commonplace defect. > >> To me, "unsafe" means "misuse can cause unpredictable behavior". > >> Array indexing is safe in Ada (you get a run-time error if > >> you go out of bounds), but unsafe in C (anything can happen > >> if you go out of bounds). What matters to you regarding software safety is quite different than what = matters to the National Transportation Safety Board (NTSB) and the Federal = Aviation Administration (FAA). If a fatal runtime error due to an unimplem= ented method (which Ada would catch at compile-time, but Swift & Objective-= C would catch only at runtime via the equivalent of an exception whose defa= ult behavior is to stop executing the entire program), then if that fatal r= untime error causes any sort of dangerous mishap (e.g., near miss; crash; c= ollision; fire) due to the software no longer performing its function, then= the NTSB and/or FAA rightly would identify that fatal runtime exception an= d the lack of method-implementation that Ada (and C++ and a very few other = languages) would have caught at compile-time as the root-causes of the dang= erous mishap. This becomes ever worse if the dangerous mishap causes injur= y or death. Whoever caused those 2 root causes might expect to be defendin= g themselves in at least wrongful-death litigation if not more-severe court= cases in the aftermath of investigating the unsafe software. So with only a modicum of respect for Mr. Duff's picayune definition of saf= ety of a software system, I reject the excessive narrowness of that definit= ion and replace it with: if the software fault (e.g., unimplemented method= in Swift or Objective-C accompanied by the -->default!!!<-- handling of th= at fault of fatal exit of the entire program) can cause bodily injury or lo= ss of life then the software is unsafe. Mr. Duff itemizes one avenue to tr= avel to arrive at unsafety, but Mr. Duff's picayune definition of safety do= es a disservice in forestalling all consideration of the other avenues to a= rrive at unsafety (i.e., casually arrive at an outcome of bodily injury or = loss of life when the state-of-the-art infrastructure would have easily det= ected at compile-time the root cause months, years, or decades before the i= njury or loss of life).