Ensmenger & Flowcharts


8 July 2017

One of the questions that keeps me awake (during the day) is the following one:

What did a “computer program” mean to Actor X in 1973?

For example, both Christopher Strachey and Edsger Dijkstra viewed a “computer program” as a mathematical object, albeit of a very different kind [1]. (A decade or more earlier, both men did not associate computer programs with mathematical objects pur sang). But what about large parts of the North American computer industry in 1973? How did actors in this field view a “computer program” in 1973?

Nathan Ensmenger's talk on flowcharts, which he gave on July 6th, 2017, at Siegen University [2], sheds light on this very question. Ensmenger made several points, most of them can be found in his article `The Multiple Meanings of a Flowchart' [3]. What struck me most is the following observation: in the 1970s many programmers in the USA were making an analogy between flowcharts and blueprints on the one hand, and between computer programs and buildings on the other hand. I call this development the “flowchart-as-blueprint” analogy, using Ensmenger's terminology.

My thoughts, so far, can be summarized as follows:

  • In the early 1970s, academics, such as Strachey, Hoare, McCarthy, Dijkstra (*), eschewed flowcharts and appropriated the term “computer program” to mean a mathematical object of some kind. (Specifically, the program text had a formal syntax and the quest for a formal semantics had long begun.)
  • By contrast, many people in the computer industry compared, or continued to compare, a “computer program” with a concrete physical object, such as a building. They had flowcharts in order to reason abstractly about their computer programs (at least in principal).

To illustrate the last item, I borrow Ensmenger's citation of McInery & Vallee's 1973 statement:

Flowcharts are to programmers as blueprints are to engineers. Before a construction engineer begins in building, he draws detailed plans from which to work. These plans are called blueprints.


Before a programmer begins to code a program into one of the computer languages (such as COBOL or ALGOL), you must have a detailed blueprint of the steps to follow. The blueprint is known as a flowchart.


Engineers and construction foremen must be able to draw and read blueprints. Programmers must be able to draw and read flowcharts. Flowcharting is a necessary and basic skill for all programmers. [6]

So, Ensmenger addresses the question “What is a flowchart?”, and by doing so he sheds light on the question “What is a computer program?” (A flowchart is like a blueprint, and a computer program is like a building.) As a result we gain a better understanding of what software entailed in large parts of North American industry in the 1970s.

Also in his talk, but not in his paper, Ensmenger referred to some work of Friedrich Bauer. Now, Bauer was first and foremost an academic software engineer, not a computer specialist working solely in industry, and even less an academic computer scientist. In fact, as editor of the 1973 book Software Engineering: An Advanced Course [4], he used both the preface and an appendix to explain where software engineering as an academic discipline had to belong. “Software engineering,” he wrote on page 523, is “that part of computer science, which is too difficult for the computer scientist.” The next historical question, then, is:

What did a “computer program” mean to F.L. Bauer in 1973?

Did Bauer subscribe to the flowchart-as-blueprint analogy? That is, did he continue to view a computer program as mostly (if not purely) physical, as he had presumably done himself in the very early days of computing? Or did he follow the formal methodists in computer science by (essentially) equating a computer program with a mathematical object? (This conceptual slip of the tongue, or conceptual oversight, made by formal methodists, is the controversial topic of my recent book [1].)

The answer is “no” on all accounts. For Bauer “software” — which I take here to be at least a bit synonymous with “computer program” — is neither physical, nor solely mathematical. In Bauer's words:

[S]oftware is not a physical object, it is non-material.

It needs physical objects as carriers only, and it is altogether unspecific about the carrier.

Since the material is cheap — paper as a carrier is sufficient [...]

[S]oftware is an abstract web, comparable to mathematical tissue, but it is a process and in so far very different from most of usual mathematics, too. [4, p. 524-525]

Having provided this rather unique choice of words, my educated guess, nevertheless, is that Bauer was only one of many to characterize software as a process. But, reflecting and carefully placing software not entirely among abstract objects (mathematics), nor in the category of physical objects (civil engineering), seems to have been much less common.(**) In retrospect, then, and with a bit of an exaggeration, I take Bauer's 1973 viewpoint to be a precursor of Raymond Turner's recent analysis in which he introduces a category of technical artefacts in order to give “computer programs” a proper philosophical treatment [5].

As a brain-washed academic myself (loving mathematics four days a week instead of three), my reading of Ensmenger's historical exposition reconfirms that treating computer programs as non-mathematical entities was not exceptional at all, and this was not so long time ago either. This non-mathematical view has presumably remained dominant in industry. I believe that even the flowchart, which was perceived as abstract (and akin to a “mathematical algorithm,” using Ensmenger's terminology once again), was mostly not associated with mathematics proper in any direct way, at least not in industry.

In sum, we already have three different 1973 viewpoints on what a “computer program” entails:

  1. Strachey, Dijkstra, and other computer scientists
  2. USA industry
  3. Bauer and other software engineers

(There were more viewpoints, and they are also very much present today.)

Why all this fuss about the definition of a computer program or, if you like, the underpinnings of software? Just like Bauer (illustrated above) and Strachey (not illustrated here), I, too, want to get a firm grip on the foundations of programming, but preferably programming tout court (and not just programming fundamentals of one particular paradigm), and partly for the sake of computer science itself. Clearly, these philosophical foundations do not yet exist, contrary to popular belief. Or, if they do, as in the form of Turner's work, they have yet to be widely disseminated and scrutinized.



(*) Dijkstra still called himself a “software engineer” in 1972, but was in the process of becoming a “computer scientist,” in accordance with the (shifting) definitions of Dijkstra, Reynolds, and the like.

(**) Bauer's 1973 view is still highly controversial today: many academics place software in the category of mathematical objects, as I have written about in my recent book [1], and as I have been told by more than one careful reviewer. 



  • [1] E.G. Daylight, Turing Tales, Lonely Scholar, December 2016.
  • [2] Conference at Siegen University, Computing is Work!, July 6-8, 2017.
  • [3] N. Ensmenger, `The Multiple Meanings of a Flowchart,' Information & Culture: A Journal of History, Vol. 51, Nr. 3, 2016.
  • [4] F.L. Bauer (ed.), Software Engineering: An Advanced Course, Springer-Verlag, 1973.
  • [5] R. Turner, `Programming Languages as Technical Artefacts.' In: Philosophy and Technology, 27.3 (2014).
  • [6] Thomas McInerney and Andre Vallee, A Student’s Guide to Flowcharting (Englewood Cliffs, NJ: Prentice-Hall, 1973.)


"We are captured by a historic tradition that sees programs as mathematical functions and programming as the central practice for translating these functions into working systems." — Peter J. Denning in 2004