What is wrong with Fortran? This is one of the oldest programming languages--the first Fortran compiler was delivered to a customer in 1957, a product of a project led by John Backus in 1954. LISP, another programming language pioneer, was invented in 1958. And yet, the differences between the two languages could not be greater: computer scientists regard Fortran as a language to be avoided, since dabbling in it can lead to permanent head damage; LISP is still, after all these years, exalted as a hacker’s language.

Still, Fortran is continuously in use and has always been the language of choice in scientific computing. This is a field distinct from mainstream software development, with its own dialect: programs are called codes and computing nodes are called compute nodes. Intriguingly, compute nodes include the most powerful computational machines available, where Fortran codes that simulate global climate or atomic weapons are heavily developed and executed on a daily basis.

To set things straight, I did not know Fortran before I started reading this book. What brought about this review is a decades-long curiosity about what Fortran is like, coupled with encounters with members of the scientific computing community.

This is not a book for learning Fortran. It is a comprehensive treatise of the language that complements the latest incarnation of the Fortran standard. It reminds a programmer of another book [1]. There is only one full program in the text, 14 lines long, at the end of an introductory chapter. The rest of the material is introduced in snippets. It is not meant to be read from cover to cover--although it is written well enough that one might as well do that--but to impart to the readers complete information on the specific subject they are interested in.

It is particularly remarkable to see how much Fortran has changed over the years, while maintaining compatibility with earlier versions. This is no minor feat, especially at a time when new library releases break code regularly. The only time when this continuity broke was in the migration from Fortran 66 to Fortran 77, and there is the feeling that this is still bitterly regretted. Source programs may or may not follow specific formatting and layout conventions. Now, Fortran programmers have at their disposal features from modern object-oriented programming languages. The book does a good job of explaining all these in depth, meriting it a place on serious Fortran developers’ bookshelves. It will also help non-Fortran developers who want to understand and read Fortran programs, although it will not make them genuine Fortran programmers.

As to what is wrong with Fortran? C++ and Java programmers reading the book will realize that they can do with Fortran pretty much everything they do in their own languages, often using similar constructs in the latest version of the standard. The problem, then, is that they might decide to stick with the real McCoy.