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

[Van Snyder]

On Thu, 2016-07-07 at 18:49 +0000, Whitlock, Stan wrote:
> 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?

Nobody got fired.  The $300 millions of taxpayer money was not recovered
from Lockheed, who violated their contract to report the results of the
small-force model in SI units instead of Imperial units.  The managers
who canceled the fifth trajectory correction maneuver, which was in the
schedule, after a five-hour meeting of navigators, navigation software
developers, propulsion engineers, and managers had already agreed to do
it, were not castigated, let alone fired.  The fact they'd unilaterally
canceled the maneuver after those who actually understood what was going
on had agreed to it was not even in the official report.  I know about
this because I've known the manager of the navigation software
development team for nearly fifty years, and he was in the meeting.  He
was somewhat angry this had been covered up.  The ultimate cause was
Lockheed's violation of their contract, but the proximal cause was a JPL
management failure.

> 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?

NASA hasn't done anything to my knowledge, other than having a few
different administrators.  Tom might know, since he actually works for
NASA.  Caltech/JPL asked me to ask the Fortran committees for language
support, which has not been forthcoming.  That might be part of the
reason that some development teams are losing interest in Fortran.  But
they don't get units checking support from C++ or python either.

> 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?

The "lock on reliability requirements" depends on how mission-critical
the software is.  On-board flight software, such as the 1/3 million
lines of Ada in orbit around Saturn is the most critical.  The software
I work on, data analysis after download, is much less critical because a
mistake can always be corrected and the data reprocessed, without losing
the entire mission.  It's not free, but it doesn't compromise an entire
mission.

The reason we haven't been able to get funding for these kinds of
software tools is that the bean counters don't know which end of the
software to plug into the wall and which end to use to melt solder.
Whenever we ask for software tools beyond compilers thay ask "Huh? Why
do you need that?"  They appear to think that labor is free, but
software tools are too expensive to tolerate.  We even have trouble
getting funding for debuggers other than the ones that come with
compilers, such as totalview.

We have a long history of love/hate relationships with preprocessors.
It's not obvious they pay off.  We've developed and used some.  We've
bought some.  It's particularly frustrating that after buying an
apparently useful tool, and discovering bugs in it after a year or two,
the company is out of business.

> /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
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3