Here is a confession. The first drafts of this issue of De Programmatica Ipsum were written under the name “Structured Programming”. Understandably enough, the news of Niklaus Wirth’s passing triggered a prompt renaming and the choice of a somewhat narrower focus. However, Pascal’s rise in popularity during the 1970s and 1980s cannot be explained unless we elaborate on Structured Programming, and this month’s Library book is among the most important ones ever written about the subject.
The phrase “Structured Programming” implies the existence of an unstructured kind thereof. We have seen some examples of Unstructured Programming during the discussion of BASIC a few months ago. The keyword that shows the lack of structure is GOTO, of course. Pascal showed up in history as the archnemesis of BASIC, and kept this role until the rise of Object-Oriented Programming as the dominant paradigm in the 1990s, until the Delphi vs. Visual Basic debate was promptly drowned by the rise of Java and C#.
Let us analyze the genesis of Pascal, which occurred thanks to three major events that took place in the same annus mirabilis 1968.
Act one: in March, Edsger Dijkstra publishes his (in)famous “Go To Statement Considered Harmful” article in the March 1968 edition of Communications of the ACM, probably the most cited paper ever in the history of computer programming. (This paper is, by the way, reprinted on page 29 of “Classics of Software Engineering”, this month’s Library book. But let us not digress.)
Act two: in October takes place the first, now legendary, NATO Software Engineering Conference where the words “software crisis” fueled passionate discussions:
There was a considerable amount of debate on what some members chose to call the “software crisis” or the “software gap”. As will be seen from the quotations below, the conference members had widely differing views on the seriousness, or otherwise, of the situation, and on the extent of the problem areas.
As the astute reader can imagine, the lack of structure was one of the major drivers of this “crisis”.
Act three: in December, the ALGOL committee (wrongly) chooses Adriaan van Wijngaarden‘s ideas as the basis for ALGOL 68, instead of Niklaus Wirth’s much simpler proposal, historically referred to as ALGOL W.
Niklaus Wirth promptly thanked the courtesy and left the ALGOL commitee, taking with him the ideas of ALGOL W. He framed them with the family name of a famous philosopher of the seventeenth century, thus creating a programming language whose name conveys seriousness, logic, and most importantly, clarity of thought.
The first Pascal compiler (single-pass, top-down, recursive-descent based) appeared around 1970, after a failed first attempt in 1969, and the language slowly grew in popularity among teachers of computer science curricula.
Wirth told the story of Pascal in the second History of Programming Languages conference of 1993:
The primary innovation of Pascal was to incorporate a variety of data types and data structures, similar to ALGOL’s introduction of a variety of statement structures. ALGOL offered only three basic data types: integers, real numbers, and truth values, and the array structure; Pascal introduced additional basic types and the possibility to define new basic types (enumerations, subranges), as well as new forms of structuring: record, set, and file (sequence), several of which had been present in COBOL.
The major historical breakthrough of the language was, of course, the UCSD Pascal system of the University of California San Diego in 1977, at the basis of various commercial implementations, including Apple’s own version for the Apple II.
“Structured Programming” was the big paradigm of the 1970s and 1980s, well before “Object Orientation” entered the collective psyche, and Pascal was poised to be its most important messenger. The GOTO keyword was to be erased from the minds of software developers forever, following Dijkstra’s plea for sanity.
Yet… in an interesting twist of pragmatism, the first versions of Pascal did include it. Yes, you heard right; it was there, as a way to help software developers migrate their code from other languages (read, BASIC and FORTRAN) into this new world of procedures and functions. Again, let us read Niklaus Wirth’s own words, telling us the reason in his HOPL II paper:
The most vociferous criticism (of Pascal) came from Habermann, who correctly pointed out that Pascal was not the last word on language design. Apart from taking issue with types and structures being merged into a single concept, (…) he reproached Pascal for retaining the much-cursed goto statement. In hindsight, one cannot but agree; at the time, its absence would have deterred too many people from trying to use Pascal. The bold step of proposing a goto-less language was taken ten years later by Pascal’s successsor Modula-2.
Let us talk now about the actual book of this month: “Classics in Software Engineering”, a recollection of papers compiled and published in 1979 by Edward Nash Yourdon, a computer consultant and engineer well known for his work in notations used in structured and object-oriented programming.
The GOTO keyword plays a central role in the book, almost to the point of obsession; apart from Dijkstra’s paper previously mentioned in this page, there literally are four more articles with the phrase “go to” in its title:
- One in favor, by Martin Hopkins of IBM, one of the inventors of the RISC architecture.
- One against, by William Wulf.
- A third one explaining how to translate “go to” programs to “while” programs, by Edward Ashcroft and Zohar Manna.
- Finally, Donald Knuth’s own “Structured Programming with go to Statements” paper.
“Classics in Software Engineering” proudly wears its name, featuring many more lectures and papers on the subject of Structured Programming by quite a few luminaries we have talked about in past issues of this magazine: Brian Kernighan, Barry Boehm, Tom DeMarco, and Donald Knuth. To top it all, it contains a copy of another classic article by Edsger Dijkstra: his own Turing Award lecture, “The Humble Programmer”, a timeless and enlightening lecture (or audio, if you prefer) recommended to all software engineers.
And of course, the book features a contribution by Niklaus Wirth himself: “On the Composition of Well-Structured Programs”, introduced by Yourdon on page 151 as follows:
For example, after four pages of a delightful philosophical review of the dismal state of the art of programming, Wirth launches into examining a total of five sample programs – all involving an ALGOL-like pseudocode that will be somewhat unfamiliar to the average COBOL programmer, and all involving applications that he wouldn’t care about. If you’re a COBOL programmer, all I can say is, be patient! Spend the time to read through the examples and to study the code that Wirth presents; it really is worth the effort.
I do not have much more to say, so I will just paraphrase and relay the same message to the audience of 2024: if you are a JavaScript or Rust programmer, all I can say is, be patient! Spend the time to read this book; it really is worth the effort.
If you want to read more from Niklaus Wirth himself, I can only recommend his classics, some of which are freely available online: his bestseller “Algorithms + Data Structures = Programs” (1976); “Project Oberon: The Design of an Operating System, a Compiler, and a Computer” (1992, revised in 2005 and 2013); and his lesser-known “Compiler Construction” (1996). OK, here is one more, albeit not by Wirth, but about him: “The School of Niklaus Wirth” (2000).
A final observation before closing this article. As much as I love (and have frequently mentioned in the pages of this magazine) Biancuzzi & Warden’s wonderful book “Masterminds of Programming”, I cannot but feel angry (dare I say, “betrayed”?) that it does not include an interview of Niklaus Wirth, who was evidently alive and very much active in 2009. This is, however, the only complaint that I have of an otherwise wonderful book that will have its own entry in this section in the future, and I want to think that the reasons for this omission were none other than scheduling conflicts or commercial deadlines.
Cover photo by the author.
