On Fri, 27 May 2005, Wouter van Ooijen wrote:
>> I had even more extreme ideas on paper. One simple one was that
>> most programming languages don't really provide an environment where
>> dimensions and units of measure are supported.  I had described a
>> language where that might have caught the errors that resulted in
>> the failures of the european satellite launch and the mars lander.
>
> Did you lateron ever find a language that does support this? (I mean at
> compile time, whith zero run-time overhead, and without having to
> declare all the intermediate types and their operators explicitly.)

In the mid-80's there was some discussion in some of the journals and 
among compiler writers.  I ended up being too busy to produce a prototype 
of the language.  And it has been too long for me to remember names of 
some of the people involved in this.  You might look through SIGPLAN 
Notices or do other searches of journals between perhaps '84 and '90 to 
see what you can find.  It didn't appear to be a particularly difficult 
problem to build a language that would meet your conditions.  I always
wanted to see how the language would turn out.

Actually the author of TK! Solver had a firm position on correctness and 
his software automatically handled units.  We flew a group of them in to 
discuss embedding something like their product into the instrument as a 
user level programming language.  But by that point other things were 
falling apart and I never was able to get that work finished.

There were a lot of other features I had on the list for a language like 
this but I believe my notes are gone now.

Creating a culture where compact and understandable, and usually 
compile-time checkable, assertions were written before the code was 
written was one idea.  Our sanity checks were a small subset of that.
But to really do all of that well was a substantial challenge.

Again and again we found we needed to make a change in code but when we 
looked at it we saw a sequence of statements.  But there was no easy way 
to determine whether that sequencing was absolutely essential or 
completely arbitrary, or some mixture.  So I was toying with the idea of 
[[ statements... ]] and the order of the statements inside those brackets 
was arbitrary.  If the order had mattered you wouldn't have used that 
notation, and thus I was trying to let the programmer easily show when 
order mattered and when it didn't.  And in the environment we were working 
in we had lots of examples with "do these" followed by "do these" and the 
order within each of those "these" were arbitrary.

I was trying to put together a notation that made clear what was essential 
in a program and what was arbitrary but just needed to get done.

>> When I asked them how they ensured that their product would have no 
>> failures they proudly announced that they used fault trees.
>
> Not a bad approach, but only for problems that are somehow 'visible' in 
> the design.
>
>> He explained that every major disaster, Three Mile, Brown's Ferry, the 
>> Apollo fire, Bo Pol, Chernobyl, etc.  all had had a careful analysis 
>> and complete fault tree constructed, that all the fault trees seemed to 
>> guarantee was that the failure would be outside what you had thought 
>> of.
>
> These kind of analysis never (at least to my knowledge) take human
> (mis)behaviour into account. Humans have a bad tendency to concentrate
> their errors on the timescale, which circumvents checks, redundancy,
> etc. They also tend to use override functions to compensate for lack of
> maintenance, lack of knowledge etc.

You are correct in that some of the major disasters were the result of the 
operators intentionally shutting off safety measures, often for testing, 
or intentionally carrying out some action outside the approved mode of 
operation. Bo Pol and Chernobyl were both examples of that.  Some fault 
analyses try to take these sort of behaviors into account.  But, again,
fault trees only seem to list off all the things that won't ever go wrong 
and don't really do a lot to avoid the serious mistakes that will happen.

> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: www.voti.nl/hvu
>
>
> -- 
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist