Sunday, January 22, 2006

The Elements of Programming Style

I have happened to notice our school library provides this book, written by [Kernighan](http://cm.bell-labs.com/cm/cs/who/bwk/) and [Plauger](http://www.plauger.com/).

I found the guidelines not as surprising as the fact that our library has a copy---the book is a classic, after all,
and often quoted. Although some of the guidelines are Fortran-specific, most of them are still valid; it was
useful to read them all in one place.

I found other aspects of the book much more interesting, though:


Most important was the realization how different was the computing world when computing power was scarce:

* At least some people would rather keep (and even publish) a convoluted and unreadably formated program that was working (or seemed to be working) than spend computer time making it readable.

* Fortran `FORMAT` commands can contain literal strings: instead of surrounding the string by quotes, the programmer would count the characters and prefix the string with the character count.

* Fortran provided a standard way to input floating-point numbers with an implied floating point (presumably to
make the data more compact).

* Variables had names because they are "really necessary", but labels had only numbers in Fortran.
(Standard Pascal brings this tradition to the extreme by providing only numerical labels *and* requiring them
to be declared in advance.)

Second, my view of Fortran changed; I no longer consider Fortran a bad language, designed without the necessary hindsight. While Fortran
indeed lacks good control structure facilities, support for strings, or dynamic allocation, it is very well suited for number crunching: there is little need for elaborate
data or control strcture, and the `FORMAT` statements allow I/O of vectors
of numbers with minimal hassle and let programmers focus on the main computation. Fortran is apparently the first surviving domain-specific language, and---dare I say it---the first scripting language (although designed for working with numbers instead of text).

It seems that the `FORMAT` facilities were a bit too powerful, causing programs to require fixed-column
input instead of something more user-friendly simply because it was much easier to parse fixed-column input.

Finally, the book suggests programming first in an "easy-to understand pseudo-language", and the examples and terminology are distictly C-like. Even though it is now obvious the translation could be done by a computer,
there is no hint of such a possibility, nor any complaint about Fortran having inadequate control structure
facilities for the tasks it was used for. The time was not right yet for such a waste of computer time, I guess.

2 comments:

  1. The C-like language you mention is, IIRC, called "ratfor". This is a FORTRAN with control constructs as you mention it, and it was presented in the "Software Tools" book by the same authors. If I recall correctly, there are FORTRAN and Pascal editions. At least one of them, and I think both presents the actual Ratfor pre-processor.

    Amazon link for "Software Tools":
    http://www.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X

    ReplyDelete