The format of the Fortran IV below looked “rs” in youtube viewer. I have got a better result here by leaving out leading spaces in lines. This means that the code will need to be hand-edited (or possibly machine edited) before submitting to a Fortran IV compiler.

This is an examination of Fortran IV code from 1975-1976. What do you think?

This code was not well received by my supervisor. I am wondering now if the reason was that there are redundancies in the specification of the input data,
(i) an extra PAGE record at the end of each chunk, which may be redundant
(ii) a record at the start of each chunk , which may be blank.

IF these are redundancies, then, strictly, by Occam’s razor, they are design faults. It may have been embarrassing to have someone write code that highlighted these issues. I suspect that these oddities were specified because the specifier thought this would make it easier to code. It could only make it easier to code, for someone who does not know how to code properly.

It was quite funny to have incompatibilities (where the code looked ok in one editor but then would not display correctly in the youtube viewer). If the work was being done by one person, they would be told that their work is of unusably low standard. Because the work is done by the industry leader (and I don’t mean youtube), everyone seems to accept it as normality.

My theory is that the industry leader does not do this deliberately - they just happened to notice that their most buggy software is the most profitable - I don’t know why. “Presumably, if they released software that had no bugs, no one would buy it”.

“As far as I know”, the code was used successfully from 1976 for some years, and never failed.

I do not know of any bugs in the code. I looked at it this week in an attempt to infer the requirements.

Any comments on the code are welcomed.

From reading the code, it appears to me that the input consists of a sequence of items, where each item is a “column of data”. A “column of data” consists of a record, followed by a PAGE record, followed by zero or more records which are not RISE records,followed by a RISE record, followed by a PAGE record.

If anyone can offer an explanation for the format of the input data, please let me know by commenting on this post.

I suspect that the first record is blank. I also suspect that the second PAGE record,
which occurs at the end of “column of data”, may be a redundant copy of the first PAGE record, and is put there because the specifier thought that this would make the code easier to write. By Occam’s razor, this is a design fault in the program specification, because it specifies something that is not required, and is therefore unnecessary and should not be there. Maybe this is why my supervisor was so offended by my code.

This is the code for subroutine PROCC
which processes one column of input data.
The code for PRFORM which calls PROCC, and processes all the input data,
has been presented already in the post titled HISTORY 004.

SUBROUTINE PROCC
C use: move one column of input data to output.
C write the output page when it is full.
COMMON/CERR/ERRIN
LOGICAL ERRIN
LOGICAL LMATCH, RD
COMMON/CCOL/ICOL
COMMON/CLINE/LINE
C input
IF (RD(DUMMY)) RETURN
LINE = 1
C output
CALL EMIT
C read a record - branch on EOF
IF (RD(DUMMY)) GO TO 5

C if not “PAGE” record, error exit
IF (LMATCH(4HPAGE)) GO TO 10
C error handling - “PAGE” record not found
5 CALL ERR(3)
ERRIN = .TRUE.
RETURN
C output
10 CALL EMIT
C read a record - branch on EOF
20 if (RD(DUMMY)) GO TO 90
C if “RISE” record, exit from loop to place output at bottom
C of column
IF (LMATCH(4HRISE)) GO TO 30
C error exit if too many lines
IF (LINE.LT.37) GO TO 15
CALL ERR(4)
ERRIN = .TRUE.
RETURN
C output
15 CALL EMIT
GO TO 20
C set line to “RISE” position at bottom of column
30 LINE = 37
C output
CALL EMIT
C read a record - branch on EOF
IF (RD(DUMMY)) GO TO 45
C if not “PAGE” record, error exit
IF (LMATCH(4HPAGE)) GO TO 40
45 CALL ERR(5)
ERRIN = .TRUE.
RETURN
C output
40 CALL EMIT
C step column count
ICOL = ICOL + 1
IF (ICOL.LT.8) RETURN
C print full page of 7 columns
CALL WRIT
ICOL = 1
RETURN
C error handling - EOF on labels file before “RISE” record found
90 CALL ERR(6)
ERRIN = .TRUE.
RETURN
END

Question 1. What is the purpose of the code?
(Is it possible to discover this by reading the code?)
Question 2. Is the code fit for purpose?

Question 3. Is it possible to write better code to do the same job?Duration : 0:0:2

some e-mail exchanged between me and William Waite, until recently, Professor at Colorado.

On Tue, Sep 18, 2007 at 10:18:49PM +1000, Mullins wrote:
It’s nearly 2 years since I wrote, and have not yet replied to your
question about what prompted me to write.

I noticed that you retired last year, so I wasn’t thinking it was very
likely that this e-mail would reach you.

My reason for writing now is to ask do you know anyone who is able to
assess the quality of Fortran IV code?

WAITE: “Quality” is, of course, in the eye of the beholder!

me: Ideally, it would be possible to have some advanced tool which could
do this (just as people want to use theorem provers to prove code correct).

WAITE: Grumble… I think that quality judgements tend to be much more heuristic, and therefore outside the realm of even an advanced tool. We can certainly verify that a program adheres to some set of coding standards, but that doesn’t necessarily equate to quality.

me: However, it would not be necessary to have an automated method to
assess the quality of code. It would be possible to manually make
assertions about what the code was intended to do, and to check these
manually, either by running the code, or perhaps by checking it by eye.

WAITE: This sounds more like correctness than quality to me.

me: Besides yourself, Dijkstra and Brinch Hansen were names that
immediately came to my mind in 1976 (as people who might have been
experts in Fortran IV), but they are now deceased. Also, I am not sure
if Brinch Hansen knows anything about Fortran. I am not even sure if
Dijkstra knew much about Fortran, because he may have left it for Algol, long before Fortran IV.

WAITE: Dijkstra considered Fortran to be an “infantile disorder” and PL/1 a “fatal disease”. I doubt very much that he would have made any other judgements about the quality of specific programs.

Jeanne Adams would be one of the people I would have recommended, but unfortunately she is also now deceased. Walter S. Brainerd is a possibility — I haven’t found an obituary for him!

But actually, Fortran is alive and well in many places. Our local scientific computing shop, NCAR, uses it heavily.

me:
Yours truly
Richard Mullins

—–Original Message—–
From: William Waite [mailto:William.Waite@Colorado.EDU]
Sent: Wednesday, 19 October 2005 2:31 AM
To: Mullins
Subject: Re: STAGE2

On Tue, Oct 18, 2005 at 01:20:21PM +1000, Mullins wrote:
Dear Dr Waite.

Regrettably I missed your talk “Gurus and the Gullible” which was
held at CSIRO in Canberra in mid 1977. I was at work and did not
take off the time to attend. Installed your stage2 software in the
1970’s and 1980’s. In recent years I downloaded code from Dr
Clarence Lehman of University of Minnesota, who installed STAGE2 in
C. Your contribution is greatly appreciated.

WAITE: It’s always nice to hear from satisfied users! But may I ask what
prompted this particular message?Duration : 0:0:11

Here is some code written in Fortran IV (which I think is the same as Fortran 66). FORTRAN IV is a “subset” of natural language, in the sense that one can simply describe in natural language, what any given statement in a FORTRAN IV program does. This does not mean that it is necessarily easy to read code written in FORTRAN IV. As an analogy, let us look at someone solving a Rubik cube. They have memorised a method (known to them) for solving the cube. But an onlooker may have no idea why the particular moves are being made.

In writing code in Fortran IV, it would be possible to provide parallel documentation to explain every step that had been taken and why. (Just as this could be done for each step to solve a Rubik cube). But the developer, given time constraints, may not have provided this very extensive documentation. (Hardly anyone ever does — I have never seen it done, except in books teaching a programming language).

This is an example from code written at DAS (Specifications were given to me in late 1975. I cannot give the specifications here, as they have not been kept. However, we can “reverse engineer” the specifications from the code.

SUBROUTINE PRFORM
C USE: process columns of data repeatedly
C till end of data.
C then print out the partly filled last
C page (if it exists).
C
COMMON/CEOF/EOFIN
COMMON/CERR/ERROR
COMMON/CCOL/ICOL
LOGICAL EOFIN, ERROR
ICOL = 1

10 IF (EOFIN) GO TO 20
IF (ERROR) RETURN
C process one column of data
CALL PROCC GO TO 10
C print last page if present

20 IF (ICOL.NE.1) CALL WRIT
RETURN
END

The flag EOFIN is set by another subroutine, if we have run out of data.
Subroutine PROCC sets the flag EOFIN if it detects that data is missing.
ICOL is the column of data on the outpage page.
We loop, processing one column of data each time.

What I have written, effectively, in the above, code, is specifications that the subroutines PROCC and WRIT have to meet. I am required to write subroutines PROCC and WRIT so that the PRFORM function works correctly.

It is possible that a more advanced approach to specifying the output could have been taken — could we have defined the input and output files using a grammar? Yes, I think the developer would be free to use this idea, if they wanted to, in their development of the subroutines PROCC and WRIT.

The subroutine PRFORM above did not do very much. It assumes that PROCC will maintain the ICOL value, and that error and eof flags will be set as required.

Is this good design? I recently asked Professor William Waite (from Colorado) for his ideas on how to assess the quality of Fortran IV code. He said that “quality is in the eye of the beholder” — he did not think, that Dijkstra would have made any judgements about the quality of specific programs in Fortran IV, except to say that Fortran was “an infantile disorder”. But I am not certain that Dijkstra knew much about Fortran IV - I think he had abandoned Fortran many years before Fortran IV arrived.Duration : 0:0:37

I suspect that languages like Prolog do not fit into the mould of today’s business hierarchies. However languages like Prolog have a future — they will still be here when today’s business management models have been abandoned and replaced.

It is said that Ken Thompson, the inventor of Unix, wrote the first version of Unix in assembly language in 1969. He begain to rewrite it in Fortran IV but gave up after a day or a week, and used C which was derived from Martin Richards’ language B, derived from BCPL. (B is still available (2007) free as a download from Richards at Oxford or Cambridge). As far as is known, no one has yet implemented Unix in Fortran (or Java).
Fortran was fairly portable. However, different computers had different word sizes, so it was easy to write Fortran code that was not very portable. Waite’s SIMC and STAGE2 systems were “portable” (though they took about a week’s work, by an expert, to get them to run on a new computer). Unix is much more portable than this. Today we expect “portable” to mean that a program will run correctly with absolutely no changes, and completely automatically.Duration : 0:0:10

Debugging fortran code from excel, and loading of critical data to model the H2O-CO2 system.Duration : 0:6:29