You are on page 1of 32
sananote ‘The Philosophy of Computer Science (Stanford Encyclopedia of Prilosopy) g Stanford Encyclopedia of Philosophy The Philosophy of Computer Science First published Tue Aug 20, 2013 For nearly every field of study, there is a branch of philosophy, called the philosophy of that field -.-Since the main purpose of a given field of study is to contribute to knowledge, the philosophy of Xis, at least in part, a branch of epistemology. Its purpose is to provide an account of the goals, methodology, and subject matter of X. (Shapiro 1983: 525) The philosophy of computer science is concerned with those philosophical issues that arise from within the academic discipline of computer science. It is intended to be the philosophical endeavor that stands to computer science as philosophy of mathematics does to mathematics and philosophy of technology does to technology. Indeed, the abstract nature of computer science, coupled with its technological ambitions, ensures that many of the conceptual questions that arise in the philosophies of mathematics and technology have computational analogues. In addition, the subject will draw in variants of some of the central questions in the philosophies of mind, language and science. We shall concentrate on a tightly related group of topics which form the spine of the subject. These include specification, implementation, semantics, programs, programming, correctness, abstraction and computation. + L Computational Artifacts © 12 Technical Artifacts ‘+ 2. Specification and Function © 2.1 Definition © 2.2 Definitions as Specifications © 2.3 Abstract Artifacts © 2.4 Theories of Function + 3.Implementation © 3.1 What is Implementation’ © 3.2 Implementation as Semantic Interpretation © 3.3 Specification and Implementation 4. Semantics ° 4 Kinds of Semantic Theory © 4.2 Programming Languages as Axiomatic Theories © 4.3 The Implementation of Programming Languages The Ontology of Program: © 5.1 Programs as Mathematical Objects © 5,2 Programs as Technical Artifacts © 5.3 Abstract and Conerete © 5.4 Programs and Specifications 6. Correctness © 6,1 Mathematical Correctness © 6.2 The Complexity Challenge o 63 The Empirical Challens. © 6.4 Physical Correctness * 7. Programming © 7.1 Programming as a Mathematical Activity © 7.2 Programming as Engineering Design © 7.3 Programming as Theory Construction pepo stanford ecentriesloompuer-scencel ise rez 2016 ‘The Philosophy of Computer Science (Stanford Encylopedia of Pilsonty) 8 Abstraction © 8.1 The General Nature of Abstraction © 8.2 Abstraction in Computer Science © 833 Information Hiding 9. Computation © 9.1 The Birth of Computability © 9.2 The Nature of Computation © 9.3 Compositionality © 9.4 The Physical Church-Turing Thesis 10, Other Topics Bibliography Academic Ti ‘Other Internet Resources Related Entries 1. Computational Artifacts ‘Computer science underpins our Facebook pages, controls air traffic around the world, and ensures that we will not be too surprised when it snows. It has been applied in algebra, car manufacturing, laser surgery, banking, gastronomy, astronomy and astrology. Indeed, it is hard to find an area of life that has not been fundamentally changed and enhanced by its application. But what is it that is applied? What are the things that give substance to such applications? The trite answer is the entities that computer scientists construct, the artifacts of computer science, computational artifacts, if you will. Much of the philosophy of the subject is concerned with their nature, specification, design and construction. 1.1 Duality Folklore has it that computational artifacts fall into two camps: hardware and software. Presumably, software includes compilers and natural language understanding systems whereas laptops and tablets are hardware. But how is this distinction drawn: how do we delineate what we take to be software and what we take to be hardware? A standard way identifies the distinction with the abstract/physical one (see the entry on abstract objects) where hardware is taken to be physical and software to be abstract. Unfortunately, this does not seem quite right. As Moor (1978) points out, programs, which are normally seen as software, and therefore under this characterization abstract, may also be physical devices. In particular, programs were once identified with sequences of physical lever pulls and pushes. There are different reactions to this observation. Some have suggested there is no distinction, In particular, Suber (1988) argues that hardware is a special case of software, and Moor (1978) that the distinction is ontologically insignificant. On the other hand, Duncan (2009—see Other Internet Resources) insists that there is an important difference but it is one that can only be made within an ontological framework that supports finer distinctions than the simple abstract/physical one (e.g., B. Smith 2012). Irmak (2012) also thinks that software and hardware are different: software is an abstract artifact, but apparently not a standard one since it has temporal properties. Whether or not the software/hardware distinction can be made substantial, most writers agree that, while a program can be taken as an abstract thing, it may also be cashed out as a sequence of physical operations. Consequently, they (e.g., Colburn 2000; Moor 1978) insist that programs have a dual nature: they have both an abstract guise and a physical one. Indeed, once this is conceded, it would seem to apply to the majority of computational artifacts. On the one hand they seem to have an abstract guise which enables us to reflect and reason about them independently of any physical manifestation. This certainly applies to abstract data types (Cardelli and Wegner 1985). For example, the list abstract data type consists of the carrier type together with operations that support the formation and manipulation of lists, Even if not made explicit, these are determined ipssplato stanford eduentiesloompuiter science! 22 rez 2016 ‘The Philosophy of Computer Science (Stanford Encylopedia of Pilsonty) by several axioms that fix their properties e.g., if one adds an element to the head of a list to form a new list, and then removes the head, the old list is returned. Similarly, an abstract stack is determined by axioms that govern ‘push and pop operations. Using such properties one may reason about lists and stacks in a mathematical way, independently of any concrete implementation, And one needs to. One cannot design nor program without such reasoning; one cannot construct correct programs without reasoning about what the programs are intended to do. If this is right, computational artifacts have an abstract guise that is separable from their physical realization or implementation. Indeed, this requirement to entertain abstract devices to support reasoning about physical ones is not unique to computer science. The necessity to abstract is clearly made by the physicist Duhem. When a physicist does an experiment, two very distinct representations of the instrument on which he is working fill his mind: one is the image of the concrete instrument that he manipulates in reality; the other is a schematic model of the same instrument, constructed with the aid of symbols supplied by theories; and it is on this ideal and symbolic instrument that he does his reasoning, and itis to it that he applies the laws and formulas of physies. A manometer, for example, is on the one hand, a series of glass tubes, solidly connected to one another filled with a very heavy metallic liquid called mereury and on the other by the perfect fluid in mechanics, and having at each point a certain density and temperature defined by a certain equation of compressibility and expansion. (Duhem 1954: 155-156) Wittgenstein talks about a similar notion of abstraction when he argues that in kinematics one abstracts away from actual physical properties. In kinematics we talk of a connecting rod—not meaning a rod made of brass or steel or what-not. We use the word ‘connecting rod’ in ordinary life, but in kinematics we use it ina quite different way, although we say rougiily the same things about it as we say about the real rod; that is goes forward and back, rotates, ete. But then the real rod contracts and expands, we say. What are we to say of this rod? Does it contract and expand?—And so we say it can't, But the truth is that there is no question of it contracting or expanding. It is a picture of a connecting rod, a symbol used in this symbolism for a connecting rod, And in this symbolism there is nothing which corresponds to a contraction or expansion of the connecting rod. (Wittgenstein 1975 [1939]: 198) Much the same could be said about computers: reasoning about them requires the employment of an abstract, machine that captures the computers function. Moreover, there is no question of abstract machines overheating or exploding Seemingly, computational artifacts have an abstract guise that supports our reasoning about them. On the other hand, somewhere down the line, they must have a physical implementation that enables them to be used as things in the physical world. This is obviously true of machines, but it is equally so for programs: programmers write programs to control physical devices. A program or abstract machine that has no physical realization is of little use as a practical device for performing humanly intractable computations. For instance, a program that monitors heart rate must be underpinned by a physical device that actually performs the task. The computer scientist Dijkstra puts it as follows. ‘A programmer designs algorithms, intended for mechanical execution, intended to control existing or conceivable computer equipment, (Dijkstra 1974: 1) On the duality view, computer science is not an abstract mathematical discipline that is independent of the physical world, To be used these things must have physical substance. And once this observation is made there is a clear link with a central notion in the philosophy of technology (Kroes 2010; Franssen et al. 2010). 1.2 Technical Artifacts ‘Technical artifacts include all the common objects of everyday life such as toilets, paper clips, tablets and dog collars. They are intentionally produced things. This is an essential part of being a technical artifact. For ipssplato stanford eduentiesloompuiter science! sas rez 2016 ‘The Philosophy of Computer Science (Stanford Encylopedia of Pilsonty) example, a physical object that accidentally carries out arithmetic is not by itself a calculator. This teleological aspect distinguishes them from other physical objects, and has led philosophers to argue that technical artifacts have a dual nature fixed by two sets of properties (e.g., Kroes 2010; Meijers 2001; Thomasson 2007; Vermaas and Houkes 2003). ‘+ Functional Properties = Structural Properties Functional properties say what the artifact does. For example, a kettle is for boiling water and a car is for transportation. On the other hand, structural properties pertain to its physical makeup. They include its weight, color, size, shape, its chemical constitution etc. In particular, we might insist that our car is red and has white seats. The notion of a technical artifact will help to conceptualize and organize some of the central questions and sues in the philosophy of computer science. We begin with a concept that underpins much of the activity of the subject, Indeed, itis the initial expression of functional properties. 2. Specification and Function In computer science, the fimction of an artifact is initially laid out in a (functional) specification (Summerville 2012; Vliet 2008). Indeed, on the way to a final device, a whole series of specification/artifact pairs of varying degrees of abstractness come into existence. The activities of specification, implementation and correctness raise a collection of overlapping conceptual questions and problems (B. C, Smith 1985; Turner 2011; Franssen et al 2010), 2.1 Definition Specifications are expressed in a variety of ways, including ordinary vernacular. But the trend in computer science has been towards more formal and precise forms of expression. Indeed, specialized languages have been developed that range from those designed primarily for program specification (e.g., VDM, Jones 1990; Z, ‘Woodcock and Davies 1996; B, Abrial 1996), wide spectrum languages such UML (Fowler 2003), through to specialized ones that are aimed at architectural description (¢.g., Rapide, Luckham 1998; Darwin, 1997; Wright, Allen 1997). They differ with respect to the underlying ontology and their means of articulating requirements. Z is based upon predicate logic and set theory. It is largely employed for the specification of suites of individual program modules or simple devices. For example, consider the following definition of a machine. The machine is to hold numerical values in locations. There are three finite sets: Store, Location and Numerals that represent the store itself, the locations of the store, and the values in the locations. In addition, there are two operations: (the declaration part of the schema) called Lookup which is a (partial) function from the Cartesian product of Store and Location to Numerals and Update which is a total function from the Cartesian product of Store, Location and Numerals to Store. These operations are governed by formal conditions that dictate the relationship between them (the predicate part of the Z schema). More specifically, they insist that if a location is updated with a new value, Lookup returns that value. Of course, any such set theoretic definition does not automatically refer to a specific physical device. That is its virtue. In order to provide its function it must abstract away from physical properties. More explicitly, it employs the abstract notion of set to introduce the update and the lookup operations as abstract set theoretic functions. As such it defines an abstract machine. UML (Fowler 2003) has a very rich ontology and a wide variety of expression mechanisms. For example, its class language allows the specification of software patterns (Gamma et al. 1994). In general, an architectural description language (ADL) is used to precisely specify the architecture of a software system (Bass 2003). Typically these languages employ an ontology that includes notions such as components, connectors, interfaces and configurations. In particular, architectural descriptions written in Rapide, Darwin or Wright are precise expressions in formalisms which are defined using an underlying mathematical semantics. For example, the ipssplato stanford eduentiesloompuiter science! an. rez 2016 ‘The Philosophy of Computer Science (Stanford Encylopedia of Pilsonty) Rapide model of computation is based on partially ordered sets of events, and its semantics is given in the Pi- calculus (Magee et al. 1995). Wright has an underlying semantics based upon the formalism known as communicating sequential processes (Hoare 1985). A specification in Rapide defines a sequence of events, and one in Wright describes an abstract process. Such expressions enable the properties of any program or system to be explored in a way that is independent of any particular implementation. But what is the logical function of the expressions of these languages? On the face of it, they are just expressions in a formal language. However, when the underlying ontology is made explicit, each of these languages reveals itself to be a formal ontology which maybe naturally cast as a type theory (Tumer 2009a). And under this interpretation these expressions are stipulative definitions (Gupta 2012). As such, each defines a new abstract object within the formal ontology of its system. 2.2 Definitions as Specifications However, taken by itself a definition need not be a specification of anything; it may just form part of a ‘mathematical exploration. So when does a definition act as a specification? Presumably, just in case the definition is taken to point beyond itself to the construction of an artifact. Itis the intentional act of giving governance of the definition over the properties of a device or system that tums a mere definition into a specification. The definition then determines whether or not the device or system has been correctly built. It provides the criteria of correctness and malfunetion, From this perspective, the role of specification is a normative one. If one asks does the device work, itis the definition functioning as a specification that tells us whether it does. Indeed, without it the question would be moot. At all levels of abstraction, the logical role of specification is always the same: it provides a criterion for correctness and malfunction. This is the perspective argued for by Turner (2011). Indeed, this normative role is taken to be part of any general theory of function (Kroes 2012), It should go without saying that this is an idealization. A specification is not fixed throughout the design and construction process. It may have to be changed because a client changes her mind about the requirements. Furthermore, it may turn out for a variety of reasons that the artifact is impossible to build. The underlying physical laws may prohibit matters. There may also be cost limitations that prevent construction. Indeed, the underlying definition may be logically absurd. In these cases, the current specification will have to be given up. But the central normative role of specification remains intact. In this regard, Tumer (2011: 57) observes that the logic of specification is not that of scientific theor 2. ...specifications are not intended to be a scientific theory of anything. If my computer does not meet its specification, I do not expect the manufacturer to supply me with a revised specification, which is what I would expect if it were fumetioning as a theory of the device. I expect to be given a computer that actually meets the original specification. With specifications itis the artefact that is correct or not; with theories it is the theory. Observe that, unlike functional descriptions, specifications are taken to be prescribed in advance of the artifact construction; they guide the implementer. This might be taken to suggest a more substantive role for specification i.e., to provide a methodology for the construction of the artifact. However, the method by which we arrive at the artifact is a separate issue to its specification. The latter dictates no such methodology. There is no logical difference between a functional specification and functional description; logically they both provide a criterion of correctness. 2.3 Abstract Artifacts Software is produced in a series of layers of decreasing levels of abstraction, where in the early layers both specification and artifact are abstract (Brooks 1995; Summerville 2012; Irmak 2012). For example, a specification written in logical notation might be taken to be a specification of a linguistic program, In turn, the linguistic program, with its associated semantics, might be taken as the specification of a physical device. In ipssplato stanford eduentiesloompuiter science! si2 serr22016 ‘The Philsopy of Computer Sciene (Stanford Eneyelopedi of Pilesoohy) other words, we admit abstract entities as artifacts. This is a characteristic feature of software development (Vliet 2008). It distinguishes it from technology in general. The introduction of abstract intermediate artifacts is essential (Brooks 1995; Summerville 2012). Without them logically complex computational artifacts would be impossible to construct. So what happens to the duality thesis? It still holds good, but now the structural description does not necessarily provide physical properties but another abstract device. For example, an abstract stack can act as the specification of a more concrete one that is now given a structural description in a programming language as an array. But the array is itself not a physical thing, it is an abstract one. Its structural description does not use physical properties but abstract ones ie., axioms. Of course, eventually, the array will get implemented in a physical store. However, from the perspective of the implementer who is attempting to implement stacks in a programming language with arrays as a data type, in her consciousness, the artifact is the abstract array of the programming language. Consequently, the duality thesis must be generalized to allow for abstract artifacts. 2.4 Theories of Function Exactly how the physical and intentional conceptualisations of our world are related remains a vexing problem to which the long history of the mind-body problem in philosophy testifies. TI situation also affects our understanding of technical artefacts: a conceptual framework that combines the physical and intentional (functional) aspects of technical artefacts is still lacking, (Kroes and Meijers 2006: 2) The literature on technical artefacts (e.g., Kroes 2010; Meijers 2001; Thomasson 2007; Vermaas and Houkes 2003) contains two main theories about how the two conceptualizations are related: causal role theories and intentional ones. Causal role theories insist that actual physical capacities determine function, Cummins's theory of functional analysis (Cummins 1975) is an influential example of such a theory. The underlying intuition is that, without the physical thing, and its actual properties, there can be no artifact. The main criticism of these theories concerns the location of any correctness criteria. If all we have is the physical device, we have no independent measure of correctness (Kroes 2010): the function is fixed by what the device actually does. Causal role theories......have the tendency to let functions coincide with actual physical capacities: structure and function become almost identical. The main drawback of this approach is that it cannot account for the malfunctioning of technical artefacts: an artefact that lacks the actual capacity for performing its intended function by definition does not have that function. The intentions associated with the artefact have become irrelevant for attributing a function. (Kroes 2010: 3) This criticism has the same flavor as that made by Kripke in his discussion of rule following, Actual machines can malfunction: through melting wires or slipping gears they may give the wrong answer. How is it determined when a malfunction occurs? By reference to the program of the machine, as intended by its designer, not simply by reference to the machine itself. Depending on the intent of the designer, any particular phenomenon may ot may not count as a machine malfunction. A programmer with suitable intentions might even have intended to make use of the fact that wires melt or gears slip, so that a machine that is malfunctioning for me is behaving perfectly for him, Whether a machine ever malfunctions and, if so, when, is not a property of the machine itself as a physical object, but is well defined only in terms of its program, stipulated by its designer. Given the program, once again, the physical object is superfluous for the purpose of determining what function is meant. (Kripke 1982: 34) The abstract machine provides the notion of correctness for the physical one. Without some independent expression of the function there are no notions of correctness and malfunction. In specification terms, the ipssplato stanford eduentiesloompuiter science! as