Bill Moffitt's Weblog

Thursday August 12, 2004

Standards bodies considered evil?

As you have probably guessed by now, I'm a big fan of openness. I wish the design of my Wenger swiss army knife were open so I could replace the useless awl with a corkscrew that I'd at least use once a year.

It follows that, if one is a fan of "open," one simply swoons at the mention of "standards," because standards are the way we codify what and how things are open. And, I admit, I am a big, big fan of standards and the extraordinary people who comprise standards committees. These bodies and the people who sit on them (my friend Keith Bierman being an excellent example) do a real service for commerce by documenting the boundaries between what is "open" and what is "closed" so innovation can happen smoothly. It's an extraordinary service for which we should all be grateful.

Now, it's confession time - I started here at Sun seven years ago, when I accepted the job of Product Manager for Sun's Fortran products. Why, you might reasonably ask, did I take such a job? Well, there were two important considerations: first, I had just been laid off (in the midst of the greatest boom in Silicon Valley history - late 1996) and, second, and most shameful, I genuinely love Fortran.

Now, that's a hard confession to make here in the 21st century by a guy who's supposed to be staying abreast of the frontier of technology, but you never lose that special feeling for your first love. (OK, that's not accurate - I confess, I had a torrid affair with Pascal, but Fortran was my first "adult" relationship, meaning that I made my living writing Fortran code for several years.) I cut my teeth writing enhancements to MSC/NASTRAN and porting it to new platforms like the Cray-1S and this new OS coming on to the scene called UNIX. It sounds antiquated, and I know I'm dating myself, but diving into the intricacies of moving code and COMMON Blocks around using the Cray overlay linker/loader, writing custom double-buffered I/O routines, and debugging code using a dump and a reader was hard work, but terribly fun. Throw in the fact that I needed to learn mechanical engineering on-the-job, and you've definitely got a job custom-built for a geek with a liberal arts degree.

But the reason I loved (and still love) Fortran (specifically FORTRAN 77) is really simple: it's human-readable. You can learn enough about Fortran to follow the logic of a simple programs in an afternoon; after a few weeks with it, someone with nearly no computer science background can write reasonably involved Fortran programs and get meaningful data from them. BASIC is the only other language I can think of that has this attribute, and it was invented from Fortran (or, as it was called then, FORTRAN.) Pascal and Algol are very readable as well, but I don't think that they can hold a candle to Fortran.

And therein lies my complaint: FORTRAN 77 was extremely readable, with modern flow control constructs (it-then-else, for instance) but very straightforward operators and data types. FORTRAN 77 was a natural outgrowth of FORTRAN 66 and added constructs and capabilities that had been in the leading FORTRAN compilers for some time and had proven to be popular.

Fortran 90 was not, in my humble opinion (and I'd encourage Keith to comment on this, as he was sitting on the ANSI X3J3 Fortran standards committee) a continuation of this trend; it is where Fortran (as it is now called) went off the rails. A more complete account of the process can be found in a 1990 article by Brian Meek, who concludes that the committee may not have gone far enough off the rails (and he makes a good case for it).

The reason is that a lot of things got added to Fortran 90 that made it less accessible to non-computer scientists and, thereby, made Fortran 90 code less readable. My favorite example of this is operator overloading, so "+" may mean something different in one example than in the next.

This is not something that had become an expected feature in Fortran compilers; it was something that was brought over from Smalltalk and C++ by folks on the standards committee who wanted to make Fortran a "modern" language. It's a feature that is familiar to computer scientists, but not one that would be intuitively obvious to a chemist. The only feature I know of in Fortran 90 that was a well-used extension in need of standardization was the pointer. If they had done Fortran right, Fortran "8x" would have been done in the 1980s, and Fortran 95 might not have even been necessary.

This was a breach of the implicit goal of a standards body: a standards body should only codify what they can agree is the de-facto standards and not drive the technology; they need to be the consumers in the marketplace of ideas, not the vendors. Indeed, to one of the points of Mr. Meeks's article, they did not unify the existing extensions of FORTRAN 77, which I believe has led to somewhat reduce the amazing portability (another one of the key advantages) of Fortran code.

The reason I offer this cautionary tale is because there are a lot more de-facto standards out there that will, in time, need to be made into formal standards to help drive all the new applications that will be made of the Internet. This, I believe, is a case where a standards body actually went awry by trying to "steer" the technology instead of documenting where it was, and I believe that was a mistake that hurt both the credibility of the body and the usability of the Fortran programming language.
(2004-08-12 14:11:38.0) Permalink Comments [2]