(j3.2006) (SC22WG5.5758) RE: RE: Units of measure
Bill Long
longb
Thu Jul 7 15:15:56 EDT 2016
On Jul 7, 2016, at 1:49 PM, Whitlock, Stan <stan.whitlock at intel.com> 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?
The screw-up was pretty clearly a program management failure. I realize that the first instinct is to divert blame. Easy to blame a language design that was ?not my fault?. But, Stan has a valid point - were the managers in charge fired?
>
> 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?
As a follow-up, you have a oft-repeated story about converting one of the NASA codes to C++. It would be straightforward to add units checking into C++. Was that included in the requirements for the C++ project?
Cheers,
Bill
>
> /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
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
More information about the J3
mailing list