Computing's Paradigm

Juergen Pabel

Undoubtly, the core aspects are very technical, but computing is also very much about social and interactional aspects. Any IT project implies a great number of challenges and more often than not these challenges must be divided among project members. The way these tasks are defined, distributed, executed and reported (for further coordination of the outstanding project tasks) has a significant impact on the result. For example, consider a software project that is created according to the Secure Development Lifecycle; a similar project developed using an agile software methodology will inadvertedly result in a vastly different software product.

These non-technical aspects are very dominant in large IT projects. More often than not, these non-technical aspects have a greater impact on the success or failure of a given project than the concrete technical challenges. I would have loved to have seen these aspects addressed in this article.

Yours,
Juergen Pabel

CACM Administrator

The following letter was published in the Letters to the Editor in the April 2010 CACM (http://cacm.acm.org/magazines/2010/4/81506).
--CACM Administrator

Beginning with the headline, "Computing's Paradigm," The Profession of IT Viewpoint by Peter J. Denning and Peter A. Freeman (Dec. 2009) reflected some confusion with respect to Thomas Kuhn's notion of "paradigm" (a set of social and institutional norms that regulate "normal science" over a period of time). Paradigms, said Kuhn, are incommensurable but determined by the social discourse of the environment in which science develops.

The crux of the matter seems to be that computing can't be viewed as a branch of science since it doesn't deal with nature but with an artifact, namely the computer. For guidance, we reflect on at least one scientific antecedent thermodynamics, which originated from the need to understand the steam engine but is distinguished from steam engineering by its search for general principles, detached from a specific machine. The Carnot cycle and entropy theorem are scientific results, not feats of engineering.

The metatheoretical problem of computing seems mainly semiotic. Suppose, 200 years ago, somebody had created a discipline called, say, Thermozap, that included the study of the Carnot cycle and the building of new steam engines. Somebody might have come up with the insoluble problem of whether the new discipline was science or engineering. It was neither but rather a hodgepodge of things better left separated.

Computing is in a similar situation. There is an area (call it Knuth-Dijkstra computing) that studies scientific problems posed by the existence of computing devices. Thermodynamics was part of physics because steam engines use physical forces. Computing devices are formal machines, so Knuth-Dijkstra computing is a mathematical discipline. Then there is the computing discipline that builds systems (call it Denning-Freeman computing), which is definitely part of engineering. The error is in thinking they are the same. Both refer to the same device, generically called "computer," but is a misleading connection, since the two disciplines describe the computer in different ways a formal model of computation in Knuth-Dijkstra computing, an actual machine in Denning-Freeman computing.

Denning and Freeman proposed a "framework" that takes the side of engineering computing (why I call it Denning-Freeman computing), describing development of an engineering system and leaving no doubt as to the envisioned nature of the discipline. All the purportedly different fields they proposed from robotics to information processing in DNA are actually different applications of the same paradigm. To consider them different would be like saying quantum physics is different for nuclear plants and for semiconductors. The physics is the same; what changes is the engineering process of its application, as in computing.

The abstract problem of symbol manipulation is mathematical and the subject of computing science. The instantiation of the symbol-manipulation model in useful systems is a problem for the engineering of computing, a discipline that is theoretically, methodologically, and conceptually separated from the mathematical study of symbol manipulation.

Simone Santini
Madrid, Spain

----------------------------------------------

AUTHORS' RESPONSE

Our argument concerned computing's "belief system." Kuhn discussed belief systems in science. Whether or not we were true to Kuhn is irrelevant to our argument.

Santini says computing is about computers. We disagree. Computing is about information processes, and computers are machines that implement information processes. There are natural, as well as artificial, information processes. Computing is as much about computers as astronomy is about telescopes.

Computing does not separate neatly into math and engineering, as Santini claims. Computing increasingly employs experimental (scientific) methods to test hypotheses about complex information processes.

Santini's desire to parse computing into separate elements will fail, just as all such previous attempts have failed. Our collective concern with information processes keeps pulling all the elements together, no matter how hard we try to separate them.

Peter Denning
Monterey, CA
Peter Freeman
Atlanta, GA

CACM Administrator

The following letter was published in the Letters to the Editor in the April 2010 CACM (http://cacm.acm.org/magazines/2010/4/81506).
--CACM Administrator

I wish to suggest ways to improve Peter J. Denning's and Peter A. Freeman's proposed computing paradigm in their Viewpoint "Computing's Paradigm" (Dec. 2009). While I accept the tentative five phases-initiation, conceptualization, realization, evaluation, and action in the proposed paradigm, they are, in practice, incomplete.

While I agree with initiation (the existential argument followed by conceptualization) as the design argument, three additional phases are missing: The first is a phase 0 I call understanding (or problem understanding). Before one can pose the existential (Denning's and Freeman's initiation), a phase must address (problem) understanding, a key element in all complex computing domains. Moreover, understanding is associated with modeling, a key aspect of understanding. One cannot determine whether a system can be built or represented without the understanding needed to pose hypotheses, theses, or formal requirements. Understanding is often not addressed very well by beginning computing researchers and developers, especially as it pertains to information processes.

The second missing element of conceptualization is an explicit statement about bounded rationality, per Herbert Simon (http://en.wikipedia.org/wiki/Bounded_rationality), a concept based on the fact that the rationality of individuals is limited by the information they possess, the cognitive limitations of their minds, and the finite amount of time they have to make decisions. Bounded rationality addresses the tentative nature of design and discovery as an evolving set of decisions posed against multiple criteria derived from understanding and initiation. The results from conceptualization, or design, must always be understood as both tentative and knowledge-limited.

Finally, a phase missing from evaluation and action is "technology readiness" (http://en.wikipedia.org/wiki/Technology_readiness_level), especially in deploying real systems. A new technology, when first invented or conceptualized is not suitable for immediate application. It is instead usually subject to experimentation, refinement, and increasingly realistic contextual testing. When proven, it can be incorporated into a deployed system or subsystem. All information processes are realized and embedded within the context of existing deployed systems. Therefore, technology readiness of a posed information process must stand as a separate phase between evaluation and action.

1. Simon, H. Bounded Rationality and Organizational Learning. Organization Science 2, 1 (1991), 125134.
2. Simon, H. A mechanism for social selection and successful altruism. Science 250, 4988 (1990), 16651668.
3. Simon, H. A behavioral model of rational choice. In Models of Man, Social and Rational: Mathematical Essays on Rational Human Behavior in a Social Setting. John Wiley & Sons, Inc., New York, 1957.

David C. Rine
Fairfax, VA

CACM Administrator

The following letter was published in the Letters to the Editor of the October 2014 CACM (http://cacm.acm.org/magazines/2014/10/178772).
--CACM Administrator

Regarding Peter J. Denning's and Peter A. Freeman's Viewpoint "Computing's Paradigm" (Dec. 2009), Simone Santini's letter to the editor "Computing Paradigm Not a Branch of Science" (Apr. 2010) said computing can be categorized as both a branch of science and a branch of mathematics, claiming, "The abstract problem of symbol manipulation is mathematical..." and "The instantiation of the symbol-manipulation model in useful systems is a problem for the engineering of computing." In response, Denning and Freeman said, "Computing does not separate neatly into math and engineering, as Santini claims." But what is indeed wrong with Santini's distinction, which has been endorsed by many others over the years? Denning and Freeman even predicted, "Santini's desire to parse computing into separate elements will fail, just as all such previous attempts have failed."

Virtually all software development is done through trial and error, (unit) testing, and never-ending patching following delivery, with stupendous (productivity) costs; recall the classic Microsoft software alert: "You may have to reboot your system." There are good reasons for this practice. One is there are no tools (or supporting theory) for systematic top-down iterative formal development, from requirements to running system. Most software products do not need meaning-preserving transformations or formal verifications.

This state of the art does not mean we can dismiss a math approach to development, validation, and annotations of library elements for machine-assisted reuse. It is actually a failure of computer science, better called "informatics," to have not developed a math approach to the software development life cycle. Consider recent unwelcome consequences of the lack of formal verification techniques: the Heartbleed flaw in OpenSSL, Goto fail in Apple OS, and the CVE-2014-1776 patch for Internet Explorer.

Though sorting belongs to one of the oldest algorithms in computer science, the Cygwin library (part of a Unix-like command-line interface for Microsoft Windows) had (still has?) an "improved" defective version of qsort with guaranteed quadratic behavior on certain inputs. In any case, I have never encountered even an informal proof that the output of a sorting algorithm is a permutation of the input.

This is not to say I think computer science should be viewed as a branch of mathematics but rather as a way to urge more research in formal techniques, hopefully yielding tools for all phases of the development life cycle. Redeveloping the Linux operating system this way would be a genuine advance, making it possible to maintain it at a high level instead of exclusively tinkering with its code.

Denning's and Freeman's response should not have demeaned Santini's distinction, endorsing again and again the pathological optimism approach (such as Scrum and Agile) to software development. In the meantime, see my Technical Opinion "Software Engineering Considered Harmful" (Nov. 2002).

Dennis de Champeaux
San Jose, CA