Keith Bierman's Weblog

Standards Do's and Don'ts Bill Moffitt makes the plausible, but naive assertion that Standards bodies should only cannonize existing practice. While I agree with many of his sentiments about what Fortran became from Fortran "90" onwards, his assertion

betrays the fact that Bill has been in Marketing too long (Bill is a good friend, and a generally sane person). Consider the plight of folks trying to get a new media type adopted, as an example of the kind of Standard that must drive technology. If the media company tools up and ships media without there being a drive that can employ it, it will certainly fail. Similarly for the drive vendors (the best removable drive, and even a standardized one, is useless without media).

More generally, anytime the "starting problem" (see my previous blog entry) rears it's ugly head, a Standards effort to drive the technology may well be an optimal approach to minimizing wasted investments, shorten the adoption curve, and otherwise improve Life, the Universe, and if not Everything, at least most things.

Now, as to the sad case of Fortran (I was on the Committee for a dozen years, and had been a formal observer for another couple before that) it's a long sad saga (and Brian Meek, who Bill references, was hardly an unbiased observer to say the least).

To make a long and painful story short enough to learn key lessons from:

1. The Committee was roughly divided into two nearly equal factions, let's call them the Progressives and the Conservatives. The Progressives wanted to create a throughly modern language that would run all existing Fortran codes, and preserve the performance characteristics that made Fortran valuable to the high performance crowd. The Conservatives felt that it was virtually impossible to ensure either of those requirements (since all real codes depended on various vendor extensions and implementation details, and the new Standard was radical enough to require a rewrite of the compilers) and that the appropriate behavior for the Committee was along the lines of what Bill suggests. (In the interest of honesty, I was on the wrong side of that issue at the time. I was a Progressive. I repented after it was too late).
2. Due to the voting rules, the Committee lurched from one side to the other, taking what had been a pretty coherent (if overly ambitious) document, tossing nearly all of it away (when the Conservatives were on the upswing) and then putting each feature back in piecemeal (losing the structural integrity of the original) over the course of many years as the Progressives recovered their majority. This was the worst of all worlds, a major update, which was very late and no longer done "well"
3. Both sides were, alas, in agreement that we needed to keep everyone in the One Big Tent. That is, to keep all of the warring factions together. Had we split into two efforts, we would have had two stronger languages. Just as Algol begat C, which begat C++ which begat Java, we would have had something like Classical Fortran as the result of the Conservatives, and something similar to Mathematica for the Progressives (well, probably not an entire environment, but a modern language without the baggage). Both could have been done faster, and probably better.
4. An example of what happens when you have two closely matched sides, there were two different user requirements for a "bit" datatype. There were two factions on the committee. As a result, no bit datatype made it into the language. The needs didn't go away; but they remain unrequited 20 years later....
   

But hindsight is better than foresight.

I think it worthy of mention that even during the worst of the battles, the individuals remained cordial and friendly relations were the norm. This was a tribute to the professionalism and to the culture that the Committee had bulit up and maintained over the course of several "generations" of membership.

This all came to an end, long after the camps largely evaporated, due to one particular individual's (a newcomer at the time) influence. It was a very striking lesson to me in human dynamics; the power (albeit negative) of one.

So a few of my lessons:

• Clearly there was (and is) great value in ensuring that all old codes continue to run. This is one of the riches of Fortran, virtually all the significant code ever written is still usable!
  
• Clearly the "starting problem" for the "progressive language" was greatly reduced (in some ways) by ensuring that the existing body of Fortran was compatible.
• But sometimes two rights make a wrong. By being a decade late, everyone suffered. Users ended up going elsewhere. Vendors ended up with huge costs to bring new compilers to market.
• Once started, an ISO standards effort will complete if there is *anyone* who wants it to ... even if it's the wrong thing. It's virtually impossible to stop. Our procedures for standards making need to be improved.
  
• There is a time for a Standard to drive technology --- usually when the technology is young. After that, Bill is right, the Committee should behave in a Conservative fashion and leave innovation to implementors ... or new Standards ... but not revisions of an existing Standard.
• While it is necessary in the US (and no doubt other venues) to permit wide participation to avoid anti-trust issues, not having any barriers to entry, or checks on membership can result in a small number (even a single individual) to wreck immense harm to the process. Behavior which would merit immediate dismissal from employment may well have no penalty (other than social) within the Committees.
  
• When a Committee is deeply divided, and the divide is nearly down the middle people should think long and hard about the advisability of "splitting up" rather than splitting heads.
  

(2004-08-16 22:58:46.0) Permalink