Plenty of books in my programming library are a bit battered and dog-eared. “Tim Hartnell’s GIANT Book of Computer Games” has almost no spine left, having been cracked open multiple times in my childhood while I typed one of its BASIC listings into my parents’ Dragon 32 microcomputer. My copy of Fred Brooks’s “The Mythical Man Month” is stamped with various libraries’ ex libris marks from defunct UK government organisations based in Harwell, Oxfordshire, starting with the Atlas Computer Laboratory (1961-1975), through CCLRC (Council for the Central Laboratory of the Resesarch Councils, 1995-2007), until I acquired it from the STFC (Science and Technology Facilities Council, 2007-present) library. The book is held together with (hopefully archival-grade) sticky tape and a plastic binding cover.
None of that comes close to the state of decay of my copy of Arthur S. Radford’s “Teach Yourself Computer Programming in FORTRAN”. As you can (not) see from the cover image, this is no longer a book so much as it is a collection of numbered sheets of paper loosely filed in a wraparound card sleeve. This is a book that has been opened and closed so much, both by myself and by its previous owner (a ballpoint inscription on the inside “cover” tells us this was a pharmacist from Bath, England), that the pages have completely separated from one another.
I think we should lay the blame as much at the feet of cheap binding as overuse, but both are present. A Teach Yourself book is designed to be read once, if at all: mostly bought by well-intentioned people who treat instructional books first as an osmotic source of information (if it is on my shelf, I will acquire the knowledge therein somehow), and then a source of embarrassment (I always meant to learn FORTRAN, but I never found the time). I find myself coming back to this book every time I need a refresher on how basic FORTRAN syntax works, which is infrequently enough that I cannot remember it, but often enough that I can readily put my hand to this book, pick it up off the shelf, then spend ten minutes trying to shuffle the pages back into the correct order.
The thing is—and this is a lesson that the rest of the computing industry would do well to recognise and to heed—everything in this book still works. FORTRAN might have evolved over the intervening decades, but never to the point where it forgot to fight for the user. Download gfortran in your favoured way, type any listing from this book into a file that you save with a .f extension, compile it, and you will find that it works in exactly the way that it did back when the book was written in 1975. Your fancy new compiler does not need program statements to start in column 6, but if that is how you write your code, that is what will work. Indeed when I typed in one of the programs just now, I got but one warning: in Fortran 2018, DO <LABEL>...<LABELED STATEMENT> was formally deleted in favour of the DO...END DO construct, introduced in MIL_STD_1753 and standardised as part of Fortran 90. Never fear, dear reader, my code still compiled and worked, it just had a warning.
And do not get confused into thinking this is a book for teaching FORTRAN programming. It is a book that teaches “Computer Programming in FORTRAN”, so you also learn how to decompose problems into sub-problems, how to model program logic with flowcharts, and how to distinguish text files encoded with EBCDIC from those encoded with ASCII. The author opens his preface with “There can be no doubt about it, the computer is here to stay.” He is correct, and 51 years on from that writing, the computers that stayed around are just as capable at running Arthur Radford’s FORTRAN code as the computers he used when he wrote the book.
Cover photo taken from the Internet Archive.