Thursday August 12, 2004 Bill Moffitt's Weblog
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.