Search in Book Reviews

As I have become involved with porting legacy FORTRAN 77 code, the appearance of the words "Structured" and "Disciplined" in the title caused me to hope that this would be a relatively good book, considering the inherent drawback of the language involved. Unfortunately my optimism was too... optimistic. I was not so naive at the beginning as to hope that the co-authors would overcome the deficiencies of FORTRAN 77 (for example, the maximum identifier length is still six characters long in FORTRAN 77), but I hoped that it would be more blatant in its reservations concerning error-prone parts of the language and actually encourage fairly good practice for its time. Though early parts of the book contain acceptable advice, better programming techniques should have been introduced much earlier (so as to be mentally absorbed by repetition throughout the book), examples include the late introduction of functions on Page 237; and symbolic names were used for constants throughout the book, but these symbolic names were for FORTRAN variables instead of FORTRAN constants and it was only in the last chapter that it was shown how to use the language to enforce constancy with the PARAMETER keyword. Much worse, promotion of error-prone techniques (examples include not bothering with explicitly declaring the datatypes used; and the COMMON keyword for placing variables in the same memory location) and dangerously incomplete descriptions of major parts of the language prevent any recommendation to use this book, despite some good tips. The main dangerously incomplete description is the lack of a warning that FORTRAN compilers accept mismatches between formal parameters and actual parameters, which in the year 2008 is still a common problem with FORTRAN.

In 2007, looking at the Usenet newsgroup news:comp.lang.fortran was more productive in discovering major extant flaws in Fortran than reading this book. However, newer Fortran standards have added more problems than those restricted to FORTRAN 77. I learnt from this book of the bizarre addition in FORTRAN 77 of a rule making whitespace in an identifier irrelevant, but that is mild in relation to newer examples of how the language becomes worse.

Otherwise better languages rely on libraries or work-arounds for some of the in-built mathematical capabilities of FORTRAN which boasts non-integer exponents and a COMPLEX data type. Of the four books which I have read from cover to cover with substantial FORTRAN in them (two books on numerical methods and two books on FORTRAN programming), this one has by far the most coverage and usage of the COMPLEX data type. How much? Barely more than a paragraph. However, an in-built COMPLEX data type mattered to one FORTRAN programmer I once met at a conference.

The first apparent syntactic influence of FORTRAN 77 (as opposed to earlier FORTRAN versions) on another language seems to be the adoption of the colon for an array range in MATLAB. Though using a colon in a range was copied from FORTRAN 77, it was in turn copied from ALGOL, which may have copied it from somewhere else for all I know. (Did you know that ALGOL 68 was not the last version of ALGOL? A newer version was published after FORTRAN 77. Some people do not know when to give up.)

This edition of the book is dated 1983, and the first edition was dated 1978 and was also supposedly on FORTRAN 77. However, the aforementioned issue with the PARAMETER keyword is a piece of evidence that FORTRAN 77 was not the primary educational theme throughout the 1983 edition so I doubt that the 1978 edition differed in this regard. Too much was written with a FORTRAN 66 mindset, with some FORTRAN 77 enhancement tacked on before it went to print.

In the preface, the style of programming taught in the book was misleadingly described as "structured" and leading to "well-designed" programs. Such immodest boasts have been made for many things throughout the history of computers, though you may need to substitute the word "structured" for another word in other decades. Instances of code replication encouraging unmaintainable messes when scaled up abound in this book such as on Pages 74; 79; 101; 107; 256; and 358, for example

IF((HRSWRK .LT. 0.0) .OR. (HRSWRK .GT. 60.0)) THEN
     PRINT *, 'ERROR IN INPUT DATA'
     GOTO 101
   ELSIF((WGRATE .LT. 0.0) .OR. (WGRATE .GT. 10.0)) THEN
     PRINT *, 'ERROR IN INPUT DATA'
     GOTO 101
   ELSIF((DEDUC .LT. 0.0) .OR. (DEDUC .GT. 35.0)) THEN
     PRINT *, 'ERROR IN INPUT DATA'
     GOTO 101
ENDIF

on Page 107 which reminded me of a more recent book with a giant case statement every branch of which contained nothing except identically copied and pasted instructions. That was a book by the overrated Grady Booch on software "engineering" with "object-oriented techniques" to address the "software crisis".