 |
 |
On Thu, 2016-03-24 at 08:35 -0400, Tom Clune wrote: > The president of the committee has indicated that the process will > rely heavily on _use cases_. I.e. the proposer will need to explain > likely/relevant scenarios for which the new feature significantly > improves the implementation. I have 58 pages of use cases, collected from more than 600 developers at JPL during the last 53 years of using Fortran. The table of contents is nearly four pages. Many of the proposals have been repeatedly requested by other Fortran user communities. The fact that the list hasn't dwindled suggests that use cases don't actually carry much weight. (Actually, item 2.7.7.7 has been implemented in the currently-proposed revision; I could remove five lines from the paper.) I'm happy to send it to anybody who wants it. When Ada was still called DoD\1 (about 1976), the organization at DoD that became AJPO asked our group at JPL to review the requirements and specifications. Among numerous other comments, on every version of the requirements from Strawman to Steelman, as well as on the final Red, Green, Blue, and Yellow proposals, we proposed that a high-reliability language ought to include a system of measurement units (actually dimensions, so that kilometers could be distinguished from centimeters). Col. Whittaker said "Huh? Why would we want that?" We proposed it for Fortran in about 1997, and perhaps as early as 1986 (I've lost my correspondence concerning Fortran 90 development). After the Mars Climate Orbiter arrived 67 kilometers too low at Mars because of an error in measurement dimensions for momentum (pound seconds instead of Newton seconds), resulting in the loss of a $300 million mission, I developed a proposal in the form of a Type II Technical Report -- now called a Technical Specification. Despite that spectacularly expensive use case, the proposal has met an unwelcome reception several times. So much for the "use cases" excuse. At the last two WG5 meetings, I asked again for permission for a project to produce a Technical Specification, and was rebuffed again. At the most recent (Delft) meeting, I offered to remove the paragraph that promises to incorporate it into the next revision, so that developers could add it to their product (or not) depending upon their customers' priorities. If the "piling more work on vendors" excuse were real, that should have had some effect, but it was met with silence. I pointed out that my sponsors want to know why a feature that is so obviously useful in a language oriented toward solving scientific and engineering problems isn't wanted. I was twice promised that a response would be forthcoming, but so far we still have no clue what the resistance is. This suggests that even one spectacularly expensive use case, and continuing use cases having significant but diffused expense, do not actually carry much weight. (Have you ever spent a week tracking down a mysterious bug, only to discover that your program has sin(latitude) instead of sin(latitude*deg2rad) in one place?) The "use case" excuse looks more like a smoke screen. At JPL, we review the proposal from time to time and have found no reason to change anything for several years. Between internal JPL reviews, and informal reviews by J3 and WG5 members, the proposal now has seen 18 revisions. We believe the proposal is complete. The only action necessary for J3 and WG5 is to read it once more and vote on it, then for ISO to publish it. A total of about one hour of plenary time would be needed.