Re: a new language, designed for safety !

["Dan'l Miller" <optikos@verizon.net>]

On Thursday, June 5, 2014 5:40:24 PM UTC-5, Robert A Duff wrote:
> "Nasser M. Abbasi" writes: 
> > 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 and is not a safety-critical software system.

Currently in the popular press, General Motors ignition-switch recall has strong resemblance to Mr. Duff's picayune excessively-narrow definition of safety of a system.  For over a decade, GM fervently held the perfectly-factually-correct position that if the ignition switch has dangling from it nothing 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-position, which could cause sudden loss of power-steering and power-brakes, in turn playing a nontrivial role in a wreck, in part by surprising the driver into a panic).  Mr. Duff and GM adopt an excessively narrow definition of safety of a system here in their respective lines of reasoning.  GM's official 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 government correctly lambasted such an excessively narrow definition of safety of a system, because of a failure-mode caused by a commonplace scenario that 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 failure-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?
> 
> 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.
> 
> 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 irrelevance 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.
> 
> > 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 picayune 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. Duff, 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 "safety" of software in a safety-critical software system is itself unsafe, because 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 lulling people into believing that all of the state-of-the-art assurances & precautions have been taken to eliminate whole categories of failure of software.  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-time assurance that an invoked method actually was implemented, instead of SmallTalk'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 industry & 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 unimplemented method (which Ada would catch at compile-time, but Swift & Objective-C would catch only at runtime via the equivalent of an exception whose default behavior is to stop executing the entire program), then if that fatal runtime error causes any sort of dangerous mishap (e.g., near miss; crash; collision; fire) due to the software no longer performing its function, then the NTSB and/or FAA rightly would identify that fatal runtime exception and 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 dangerous mishap.  This becomes ever worse if the dangerous mishap causes injury or death.  Whoever caused those 2 root causes might expect to be defending 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 safety of a software system, I reject the excessive narrowness of that definition and replace it with:  if the software fault (e.g., unimplemented method in Swift or Objective-C accompanied by the -->default!!!<-- handling of that fault of fatal exit of the entire program) can cause bodily injury or loss of life then the software is unsafe.  Mr. Duff itemizes one avenue to travel to arrive at unsafety, but Mr. Duff's picayune definition of safety does a disservice in forestalling all consideration of the other avenues to arrive 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 detected at compile-time the root cause months, years, or decades before the injury or loss of life).