This is an enjoyable and thought-provoking paper by one of the founding fathers of software engineering. Wirth observes that many concepts and ideas that are advertised as new, actually existed decades ago, perhaps under different names. He believes that it is “worthwhile to occasionally consider the past.” Some of us--who still remember the time when “it was fun” [1]--may recall the need to deal only with intellectually manageable (Dijkstra) artifacts, despite the current abundance of computing resources that, in Wirth’s opinion, “inevitably reduced the attention given to good design.”

Wirth’s overview starts with the 1960s, when “there was no interactivity between man and computer” and it was essential to think before submitting a program to the computer system--the results were fetched hours or even days later. In those days, as the then-popular programming textbooks emphasized, submitting a program was (almost) like attempting to prove a mathematical theorem. Interactivity led to instant gratification, with its rewards and shortcomings. Furthermore, complexity led to failures when “systems were promised but could not be completed and delivered on time.” In 1968 and 1969, the well-known NATO conferences on software engineering openly and frankly discussed, for the first time in a public forum, programmers’ difficulties, although some publications, notably Dijkstra’s, dealt with these issues very explicitly in the early 1960s [2]. Wirth emphasizes Dijkstra’s and Hoare’s papers on structured programming that “had a profound influence on new programming languages--in particular, Pascal” (created by Wirth).

Regretfully, these developments “did not--could not--change the software situation.” Moreover, while Unix was a “highly welcome relief from the large operating systems,” it acted like a Trojan horse for C, which was “rather like an assembler code in the disguise of a remotely Algol-like syntax.” Wirth considers the rapid spread of C as a “great leap backward,”so that the term “high-level language” became a poorly understood buzzword. Most importantly, while abstraction is essential for mastering complexity, for abstractions understood only in terms of the facilities of the underlying computer, “the benefits are marginal, almost given away.” As a result, the widespread use of C “sabotaged the programming community’s attempt to raise the level of software engineering.” It was an invitation for programmers to use tricks that were possibly helpful for efficiency in the early days of computing, but that “now were pitfalls that made large systems error-prone and costly to debug and ‘maintain.’”

Newer languages, such as Ada and C++, became large and, as Dijkstra warned, “belonged to the problem set rather than the solution set.” Many language textbooks taught a (or “the”) funny way (according to Dijkstra) to represent known and trivial problems, and the same approach has been used in specification languages. A few programming texts [3,4] not mentioned by Wirth are exceptions--they teach programming concepts.

With the advent of the microcomputer, computing went mainstream. Instant gratification combined with complexity led to hacking and Dijkstra’s and Hoare’s papers, in which programming was obtaining a mathematical basis, passed “virtually unnoticed in industry.” Wirth notes, however, that thanks to the concepts of Parnas’ information hiding and Liskov’s abstract data types, introduced in the early 1970s, “modularization probably constituted the most important contribution to software engineering”; he does not refer to Dijkstra’s distinction between what it does and how it works (“divide and conquer”), explicitly formulated in the 1960s. Wirth mentions his language Modula-2, a successor to Pascal.

The era of personal workstations was characterized by “search of panaceas.” While many were forgotten, object orientation survived. It became “both a trend and a buzzword,” although, as Wirth properly observes, it is “not appropriate for all applications.” Unfortunately, Wirth does not mention the generalized object model, in which relationships among objects are explicitly recognized and dealt with.

The abundance of computer power, combined with the developments noted above, led to a situation where “the writing of complicated code ... is apparently considered easier or more economical than the careful design and description of clean interfaces of modules.” While Wirth considers open source to be “a last attempt to cover up failure,” this need not be the case--after all, program reading was noted in the 1960s, and became popular, together with egoless programming, thanks to Weinberg [5].

The “grave lack of concern for software quality ... is disquieting, and so is the complacency of customers.” In a few projects, as Wirth notes, large commercial systems were replaced with (Wirth’s) Oberon system, “whose principal design objective had been perspicuity and concentration on the essentials.” Wirth considers proper education “concerning a sense of quality” to be of primary importance, but notes that inadequate artificially complex programming languages and other such tools “have now quietly been adopted by the academic world, without debate and criticism,” leading to vocational training instead of education. Wirth observes that in our field of computing, instead of being spiritual and intellectual leaders, universities “have simply become docile followers.”

Unfortunately, Wirth does not mention domain engineering and requirements engineering--essential parts of software engineering.