(j3.2006) (SC22WG5.5758) RE: RE: Units of measure

[Whitlock, Stan]

You say:

If your organization had lost $300 million due to a trivial software mistake that the programming language and its runtime could have caught or corrected automatically, would you roll over and play dead?  If you wasted two work weeks per year chasing problems that the programming language and its runtime could have caught or corrected automatically, would you roll over and play dead?

and:

even though essentially no code generation is involved, and what little is required is trivial.  It could be done by the front end, by the equivalent of inlining trivial one-line functions, long before the real code generator gets involved.

My questions are:

1.  How many people got fired because of this screw-up that crashed the Mars spacecraft?  How much lost taxpayer money was recovered as damages from those responsible?

2.  What has NASA done since this disaster to lessen the problem impact?  You still spend 2 weeks per year chasing mismatched units?  Have mismatched units caused any other disasters?  Or has NASA eliminated the problem?

3.  You implied that JPL has an absolute lock on reliability requirements.  If providing units checking is so trivial and so important, why hasn't JPL built or contracted to be built such a checker?

/Stan

-----Original Message-----
From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Van Snyder
Sent: Wednesday, July 06, 2016 8:37 PM
To: j3 at mailman.j3-fortran.org
Subject: Re: (j3.2006) (SC22WG5.5755) RE: Units of measure

On Wed, 2016-07-06 at 16:35 +0000, Lionel, Steve wrote:
> I didn't like the particular proposal, that it felt "too F77-like" and 
> I didn't think it would solve the stated problem, but I don't remember 
> details.

In 2004, there were two who didn't like the proposal, eight who liked it, and three who loved it.  Nobody said then why they didn't like it, and other than the vague "too F77 like" nobody has yet offered a reason for not liking it.  It's difficult to revise a proposal to answer objections that nobody will reveal.  That was supposed to be the purpose of N2112, but it's quite vague also.

Even though the sentiment was 11-2 favorable, somehow it got assessed to be as big a project as coarrays, even though essentially no code generation is involved, and what little is required is trivial.  It could be done by the front end, by the equivalent of inlining trivial one-line functions, long before the real code generator gets involved.

I'm curious what's "F77 like" about an attribute for a real variable.

It was designed explicitly to solve the stated problem, so I'm curious to know why it wouldn't.

The TS proposal, with all its details, is online.  It contains 14 pages of editorial changes.  The TS on ADDITIONAL features for coarrays contained 23 pages of editorial changes.  The TS on ADDITIONAL features for C interoperability contained 21 pages of editorial changes.

If your organization had lost $300 million due to a trivial software mistake that the programming language and its runtime could have caught or corrected automatically, would you roll over and play dead?  If you wasted two work weeks per year chasing problems that the programming language and its runtime could have caught or corrected automatically, would you roll over and play dead?


_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3