7/21/2019 The Philosophy of Computer Science2 http://slidepdf.com/reader/full/the-philosophy-of-computer-science2 1/46 The Philosophy of Computer Science 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 X is, 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 !"#$ %&%' 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 specication, implementation, semantics, programs, programming, correctness, abstraction and computation. 1. omputational !rtifacts 1.1 "uality 1.# Technical !rtifacts #. $pecication and %unction #.1 "enition #.# "enitions as $pecications #.& !bstract !rtifacts #.' Theories of %unction &. Implementation &.1 What is Implementation( &.# Implementation as $emantic Interpretation &.& $pecication and Implementation '. $emantics '.1 Two )inds of $emantic Theory '.# *rogramming +anguages as !iomatic Theories '.& The Implementation of *rogramming +anguages -. The ntology of *rograms -.1 *rograms as /athematical bjects -.# *rograms as Technical !rtifacts -.& !bstract and oncrete -.' *rograms and $pecications 0. orrectness 0.1 /athematical orrectness 0.# The ompleity hallenge 0.& The mpirical hallenge 1
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 X is, at least in part, a branch of epistemology. Its purpose is to provide an accountof the goals, methodology, and subject matter of X . (Shapiro !"#$ %&%'
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 thephilosophies of mind, language and science. We shall concentrate on a tightly
related group of topics which form the spine of the subject. These include
3. !bstraction3.1 The 4eneral 5ature of !bstraction
3.# !bstraction in omputer $cience
3.& Information 6iding
7. omputation
7.1 The 8irth of omputability
7.# The 5ature of omputation
7.& ompositionality
7.' The *hysical hurch9Turing Thesis
1:. ther Topics
8ibliography
!cademic Tools
ther Internet ;esources
;elated ntries
1. Computational Artifacts
omputer science underpins our %aceboo< pages, controls air tra=c 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, ban<ing, gastronomy,
astronomy and astrology. Indeed, it is hard to nd an area of life that has not been
fundamentally changed and enhanced by its application. 8ut 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. /uch of the philosophy of the subject is
concerned with their nature, specication, design and construction.
1.1 Duality
%ol<lore has it that computational artifacts fall into two camps> hardware and
software. *resumably, software includes compilers and natural language
understanding systems whereas laptops and tablets are hardware. 8ut how is thisdistinction drawn> how do we delineate what we ta<e to be software and what we
ta<e to be hardware(
! standard way identies the distinction with the abstract?physical one @see the
entry on abstract objectsA where hardware is ta<en to be physical and software to
be abstract. Bnfortunately, this does not seem quite right. !s /oor @1723A points
out, programs, which are normally seen as software, and therefore under this
characteriCation abstract, may also be physical devices. In particular, programs
were once identied with sequences of physical lever pulls and pushes. There are
diDerent reactions to this observation. $ome have suggested there is no distinction.
In particular, $uber @1733A argues that hardware is a special case of software, and
/oor @1723A that the distinction is ontologically insignicant. n the other hand,
"uncan @#::7Esee ther Internet ;esourcesA insists that there is an important
diDerence but it is one that can only be made within an ontological framewor< thatsupports ner distinctions than the simple abstract?physical one @e.g., 8. $mith
#:1#A. Irma< @#:1#A also thin<s that software and hardware are diDerent> 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 ta<en as an abstract thing, it may also
be cashed out as a sequence of physical operations. onsequently, they @e.g.,
olburn #:::F /oor 1723A 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. n the one hand they seem to
have an abstract guise which enables us to reGect and reason about themindependently of any physical manifestation. This certainly applies to abstract data
types @ardelli and Wegner 173-A. %or eample, the list abstract data type consists
of the carrier type together with operations that support the formation and
manipulation of lists. ven if not made eplicit, these are determined by several
aioms that 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. $imilarly, an
abstract stac< is determined by aioms that govern push and pop operations. Bsing
such properties one may reason about lists and stac<s in a mathematical way,
independently of any concrete implementation. !nd one needs to. ne cannot
design nor program without such reasoningF 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
realiCation 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 "uhem.
When a physicist does an eperiment, two very distinct representations of the
instrument on which he is wor<ing ll his mind> one is the image of the concrete
instrument that he manipulates in realityF the other is a schematic model of the
same instrument, constructed with the aid of symbols supplied by theoriesF and it is
on this ideal and symbolic instrument that he does his reasoning, and it is to it that
he applies the laws and formulas of physics. ! manometer, for eample, is on the
one hand, a series of glass tubes, solidly connected to one another lled with a very
heavy metallic liquid called mercury and on the other by the perfect Guid in
mechanics, and having at each point a certain density and temperature dened by
a certain equation of compressibility and epansion. @"uhem 17-'> 1--H1-0A
Wittgenstein tal<s about a similar notion of abstraction when he argues that in
<inematics one abstracts away from actual physical properties.
In <inematics we tal< of a connecting rodEnot meaning a rod made of brass or steel
or what9not. We use the word connecting rodJ in ordinary life, but in <inematics we
use it in a quite diDerent way, although we say roughly the same things about it as
we say about the real rodF that is goes forward and bac<, rotates, etc. 8ut then the
real rod contracts and epands, we say. What are we to say of this rod( "oes it
contract and epand(E!nd so we say it canKt. 8ut the truth is that there is noquestion of it contracting or epanding. It is a picture of a connecting rod, a symbol
used in this symbolism for a connecting rod. !nd in this symbolism there is nothing
which corresponds to a contraction or epansion of the connecting rod.
@Wittgenstein 172- L17&7M> 173A
/uch the same could be said about computers> reasoning about them requires the
employment of an abstract machine that captures the computers function.
/oreover, there is no question of abstract machines overheating or eploding.
$eemingly, computational artifacts have an abstract guise that supports our
reasoning about them. n the other hand, somewhere down the line, they must
have a physical implementation that enables them to be used as things in thephysical world. This is obviously true of machines, but it is equally so for programs>
programmers write programs to control physical devices. ! program or abstract
machine that has no physical realiCation is of little use as a practical device for
performing humanly intractable computations. %or instance, a program that
monitors heart rate must be underpinned by a physical device that actually
performs the tas<. The computer scientist "ij<stra puts it as follows.
! programmer designs algorithms, intended for mechanical eecution, intended to
control eisting or conceivable computer equipment. @"ij<stra 172'> 1A
n the duality view, computer science is not an abstract mathematical discipline
that is independent of the physical world. To be used these things must havephysical substance. !nd once this observation is made there is a clear lin< with a
central notion in the philosophy of technology @)roes #:1:F %ranssen et al. #:1:A.
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. %or eample, 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 ed by two sets of [email protected]., )roes #:1:F /eijers #::1F Thomasson #::2F Nermaas and 6ou<es #::&A.
• %unctional *roperties
• $tructural *roperties
%unctional properties say what the artifact does. %or eample, a <ettle is for boiling
water and a car is for transportation. n the other hand, structural properties
pertain to its physical ma<eup. They include its weight, color, siCe, shape, its
diDer with respect to the underlying ontology and their means of articulating
requirements.P is based upon predicate logic and set theory. It is largely employed for the
specication of suites of individual program modules or simple devices. %or
eample, consider the following denition of a machine. The machine is to hold
numerical values in locations. There are three nite sets> $tore, +ocation and
5umerals 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
schemaA called +oo<up which is a @partialA function from the artesian product of
$tore and +ocation to 5umerals and Bpdate which is a total function from the
artesian product of $tore, +ocation and 5umerals to $tore. These operations are
governed by formal conditions that dictate the relationship between them @the
predicate part of the P schemaA. /ore specically, they insist that if a location isupdated with a new value, +oo<up returns that value. f course, any such set
theoretic denition does not automatically refer to a specic physical device. That is
its virtue. In order to provide its function it must abstract away from physical
properties. /ore eplicitly, it employs the abstract notion of set to introduce the
update and the loo<up operations as abstract set theoretic functions. !s such it
B/+ @%owler #::&A has a very rich ontology and a wide variety of epression
mechanisms. %or eample, its class language allows the specication of software
patterns @4amma et al. 177'A. In general, an architectural description language
@!"+A is used to precisely specify the architecture of a software system @8ass #::&A.
Typically these languages employ an ontology that includes notions such as
components, connectors, interfaces and congurations. In particular, architecturaldescriptions written in ;apide, "arwin or Wright are precise epressions in
formalisms which are dened using an underlying mathematical semantics. %or
eample, the ;apide model of computation is based on partially ordered sets of
events, and its semantics is given in the *i9calculus @/agee et al. 177-A. Wright has
an underlying semantics based upon the formalism <nown as communicating
sequential processes @6oare 173-A. ! specication in ;apide denes a sequence of
events, and one in Wright describes an abstract process. $uch epressions enable
the properties of any program or system to be eplored in a way that is independent
of any particular implementation.
8ut what is the logical function of the epressions of these languages( n the face
of it, they are just epressions in a formal language. 6owever, when the underlyingontology is made eplicit, each of these languages reveals itself to be a formal
ontology which maybe naturally cast as a type theory @Turner #::7aA. !nd under
this interpretation these epressions are stipulative denitions @4upta #:1#A. !s
such, each denes a new abstract object within the formal ontology of its system.
2.2 Definitions as Specifications
6owever, ta<en by itself a denition need not be a specication of anythingF it may
just form part of a mathematical eploration. $o when does a denition act as a
specication( *resumably, just in case the denition is ta<en to point beyond itself
to the construction of an artifact. It is the intentional act of giving governance of thedenition over the properties of a device or system that turns a mere denition into
a specication. The denition then determines whether or not the device or system
has been correctly built. It provides the criteria of correctness and malfunction. %rom
this perspective, the role of specication is a normative one. If one as<s does the
device wor<, it is the denition functioning as a specication that tells us whether it
does. Indeed, without it the question would be moot. !t all levels of abstraction, the
logical role of specication is always the same> it provides a criterion for correctness
and malfunction. This is the perspective argued for by Turner @#:11A. Indeed, this
normative role is ta<en to be part of any general theory of function @)roes #:1#A.
It should go without saying that this is an idealiCation. ! specication is not edthroughout the design and construction process. It may have to be changed
because a client changes her mind about the requirements. %urthermore, 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 denition may be logically absurd.
In these cases, the current specication will have to be given up. 8ut the central
In this regard, Turner @#:11> -2A observes that the logic of specication is not that of
scientic theoriCing.
specications are not intended to be a scientic theory of anything. If my computer
does not meet its specication, I do not epect the manufacturer to supply me with
a revised specication, which is what I would epect if it were functioning as a
theory of the device. I epect to be given a computer that actually meets theoriginal specication. With specications it is the artefact that is correct or notF with
theories it is the theory.
bserve that, unli<e functional descriptions, specications are ta<en to be
prescribed in advance of the artifact constructionF they guide the implementer. This
might be ta<en to suggest a more substantive role for specication i.e., to provide a
methodology for the construction of the artifact. 6owever, the method by which we
arrive at the artifact is a separate issue to its specication. The latter dictates no
such methodology. There is no logical diDerence between a functional specication
and functional descriptionF logically they both provide a criterion of correctness.
2.3 Abstract Artifacts
$oftware is produced in a series of layers of decreasing levels of abstraction, where
in the early layers both specication and artifact are abstract @8roo<s 177-F
$ummerville #:1#F Irma< #:1#A. %or eample, a specication written in logical
notation might be ta<en to be a specication of a linguistic program. In turn, the
linguistic program, with its associated semantics, might be ta<en as the
specication of a physical device. In other words, we admit abstract entities as
artifacts. This is a characteristic feature of software development @Nliet #::3A. It
distinguishes it from technology in general. The introduction of abstract
intermediate artifacts is essential @8roo<s 177-F $ummerville #:1#A. Without themlogically comple computational artifacts would be impossible to construct.
$o 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. %or eample, an abstract stac< can act as the specication of a more
concrete one that is now given a structural description in a programming language
as an array. 8ut the array is itself not a physical thing, it is an abstract one. Its
structural description does not use physical properties but abstract ones i.e.,
aioms. f course, eventually, the array will get implemented in a physical store.
6owever, from the perspective of the implementer who is attempting to implement
stac<s in a programming language with arrays as a data type, in her consciousness,
the artifact is the abstract array of the programming language. onsequently, theduality thesis must be generaliCed to allow for abstract artifacts.
2.4 Theories of Function
actly how the physical and intentional conceptualisations of our world are related
remains a veing problem to which the long history of the mindHbody problem in
philosophy testies. This situation also aDects our understanding of technical
artefacts> a conceptual framewor< that combines the physical and intentional
@functionalA aspects of technical artefacts is still lac<ing. @)roes and /eijers #::0> #A
The literature on technical artefacts @e.g., )roes #:1:F /eijers #::1F Thomasson
#::2F Nermaas and 6ou<es #::&A contains two main theories about how the two
conceptualiCations are related> causal role theories and intentional ones.
ausal role theories insist that actual physical capacities determine function.
umminsKs theory of functional analysis @ummins 172-A is an inGuential eample
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 @)roes #:1:A> the function
is ed by what the device actually does.
ausal role theoriesQ..have the tendency to let functions coincide with actual
physical capacities> structure and function become almost identical. The main
drawbac< of this approach is that it cannot account for the malfunctioning of technical artefacts> an artefact that lac<s the actual capacity for performing its
intended function by denition does not have that function. The intentions
associated with the artefact have become irrelevant for attributing a function.
@)roes #:1:> &A
This criticism has the same Gavor as that made by )rip<e in his discussion of rule
following.
!ctual machines can malfunction> through melting wires or slipping gears they may
give the wrong answer. 6ow is it determined when a malfunction occurs( 8y
reference to the program of the machine, as intended by its designer, not simply by
reference to the machine itself. "epending on the intent of the designer, any
particular phenomenon may or may not count as a machine malfunction. !
programmer with suitable intentions might even have intended to ma<e 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 dened only
in terms of its program, stipulated by its designer. 4iven the program, once again,
the physical object is superGuous for the purpose of determining what function is
meant. @)rip<e 173#> &'A
The abstract machine provides the notion of correctness for the physical one.
Without some independent epression of the function there are no notions of correctness and malfunction. In specication terms, the @physicalA artifact cannot
its own criterion of correctness. This argues against such causal theories of function
and specication.
Intentional theories insist that it is agents who ascribe functions to artefacts.
bjects and their components possess functions only insofar as they contribute to
the realiCation of a goal. 4ood eamples of this approach are /c+aughlin @#::1A and
$earle @177-A.
LtMhe function of an artifact is derivative from the purpose of some agent in ma<ing
or appropriating the objectF it is conferred on the object by the desires and beliefs of
an agent. 5o agent, no purpose, no function. @/c+aughlin #::1> 0:A
8ut how eactly does the function get ed by the desires of an agent( ne
interpretation has it that the function is determined by the mental states of the
agents i.e., the designers and users of technical artifacts. In their crude form such
theories have di=culty accounting for how they impose any constraints upon the
actual thing that is the artifact.
If functions are seen primarily as patterns of mental states, on the other hand, and
eist, so to spea<, in the heads of the designers and users of artifacts only, then it
becomes somewhat mysterious how a function relates to the physical substrate in a
particular artifact. @)roes #:1:> #A
%or eample, how can the mental states of an agent the function of a device thatis intended to perform addition( This question is posed in a rather diDerent contet
by )rip<e.
4iven Q that everything in my mental history is compatible both with the
conclusion that I meant plus and with the conclusion that I meant quus, it is clear
that the s<eptical challenge is not really an epistemological one. It purports to show
that nothing in my mental history of past behaviorEnot even what an omniscient
4od would <nowEcould establish whether I meant plus or quus. 8ut then it appears
to follow that there was no fact about me that constituted my having meant plus
rather than quus. @)rip<e 173#> #1A
f course, one might also insist that the artifact is actually in accord with thespecication, but this does not help if the epression of the function is only located
in the mental states of an agent. This version of the intentional theory is really a
special case of a causal theory where the agentKs head is the physical device in
which the function is located.
6owever, there is an alternative interpretation of the intentional approach. n his
commentary on WittgensteinKs notion of acting intentionally @Wittgenstein 17-&A,
"avid *ears suggests that anyone who acts intentionally must <now two things.
%irstly, she must <now what activity she is engaged in. $econdly, she must <now
when she has succeeded @*ears #::0A. !ccording to this perspective, establishing
correctness is an eternally observable rule based activity. The relation between the
denition and the artifact is manifest in using the denition as a canon of
correctness for the device. I must be able to justify my reasons for thin<ing that it
wor<s> if I am as<ed if it wor<s I must be able to justify that it does with reference to
the abstract denition. The content of the function is laid out in the abstract
denition, but the intention to ta<e it as a specication is manifest in using it as one
8roadly spea<ing an implementation is a realiCation of a specication. amples
includes the implementation of a B/+ specication in Oava, the implementation of
an abstract algorithm as a program in , the implementation of an abstract data
type in /iranda or the implementation of a whole programming language./oreover, implementation is often an indirect process that involves many stages
before physical bedroc<, and each level involves a specication?artifact pairing, and
each involves a notion of implementation. 8ut what is an implementation( Is there
just one notion or many(
3.1 !hat is mplementation"
The most detailed philosophical study of implementation is given by ;apaport
@1777, #::-A. 6e argues that implementation involves two domains> a syntactic one
@the abstractionA and a semantic one @the implementationA. Indeed, he suggests
that a full eplication of the notion requires a third hidden term, a medium of implementation> I is an Implementation of ! in medium /. 6ere I is the semantic
component, ! is the abstraction and / the medium of implementation. 6e allows for
the target medium to be abstract or physical. This is in line with the claim that
artifacts maybe abstract or concrete.
$upercially, this seems right. In all the eamples cited there is a medium of
implementation in which the actual thing that is the implementation is carved out.
*erhaps the clearest eample is the implementation of a programming language.
6ere the syntactic domain is the actual language and the semantic one its
interpretation on an abstract machine> the medium of interpretation. 6e suggests
that we implement an algorithm when we epress it in a computer programminglanguage, and we implement an abstract data type when we epress it as a
concrete one. amples that he does not mention might include the B/+ denition
of design patterns implemented in Oava @4amma et al. 177'A.
6e further argues that there is no intrinsic diDerence between which of the domains
is semantic and which is syntactic. This is determined by the asymmetry of the
implementation mapping. %or eample, a physical computer process that
implements a program plays the role of the semantics to the linguistic program,
while the same linguistic program can play the role of semantic domain to an
algorithm. This asymmetry is parallel to that of the specication?artifact connection.
n the face of it there is little to cause any dissension. It is a straightforward
description of the actual use of the term implementation. 6owever, there is anadditional conceptual claim that is less clear.
3.2 mplementation as Semantic nterpretation
!pparently, the semantic domain, as its name suggests, is always ta<en to be a
semantic representation of the syntactic oneF it closes a semantic gap between the
abstraction and the implementation in that the implementation lls in details. This is
a referential view of semantics in that the syntactic domain refers to another
domain that provides its meaning. Indeed, there is a strong tradition in computer
science that ta<es referential or denotational semantics as fundamental @$toy 1722F
/ilne and $trachey 1720F 4ordon 1727A. We shall eamine this claim later when we
consider the semantics of programming languages in more detail @R'A. %or the
moment we are only concerned with the central role of any <ind of semantics.ne view of semantics insists that it must be normative. !lthough the eact form of
the normative constraint @4lSer and Wi<forse #::7F /iller and Wright #::#A is
debated, there is a good deal of agreement on a minimal requirement> a semantic
account must what it is to use an epression correctly.
The fact that the epression means something implies that there is a whole set of
normative truths about my behavior with that epressionF namely, that my use of it
is correct in application to certain objects and not in application to othersQ. The
normativity of meaning turns out to be, in other words, simply a new name for the
familiar fact that, regardless of whether one thin<s of meaning in truth9theoretic or
assertion9theoretic terms, meaningful epressions possess conditions of correct use.)rip<eKs insight was to realiCe that this observation may be converted into a
condition of adequacy on theories of the determination of meaning> any proposed
candidate for the property in virtue of which an epression has meaning, must be
such as to ground the normativityJ of meaning9it ought to be possible to read oD
from any alleged meaning constituting property of a word, what is the correct use of
that word. @8oghossian 1737> -1&A
n the assumption that this minimal requirement has to be satised by any
adequate semantic theory, is implementation always, or even ever, semantic
interpretation( !re these two notions at odds with each other(
ne standard instance of implementation concerns the interpretation of onelanguage in another. 6ere the abstraction and the semantic domain are both
languages. Bnfortunately, this does not provide a criterion of correctness unless we
have already ed the semantics of the target language. While translating between
languages is ta<en to be implementation, indeed a paradigm case, it is not, on the
present criterion, semantic interpretation. It only satises the correctness criterion
when the target language has an independently given notion of correctness. This
may be achieved in an informal or in a mathematical way. 8ut it must not end in
another uninterpreted language. $o this paradigm case of implementation does not
appear to satisfy the normative constraints required for semantic interpretation.
5et consider the case where the abstraction is a language and the semantic
medium is set theory. This would be the case with denotational semantics @$toy1722A. This does provide a notion of correctness. ur shared and agreed
understanding of set theory provides this. Bnfortunately, it would not normally be
ta<en as an implementation. ertainly, it would not, if an implementation is
something that is eventually physically realiCable. *resumably, this is a necessary
5ow consider the case where the syntactic component is an abstract stac< and the
semantic one is an array. 6ere we must as< what it means to say that the
implementation is correct. "oes the medium of the array the correct use of
stac<s( It would seem not> the array does not provide the criteria for deciding
whether we have the correct aioms for stac<s or whether we have used them
correctly in a particular application. ;ather the stac< is providing the correctnesscriteria for the implementation that is the array. Instead, the aioms provide the
fundamental meanings of the constructs. While the array is an implementation of
the stac<, it does not provide it with a notion of correctness> the cart and the horse
have been interchanged.
%inally, suppose the semantic domain is a physical machine and the syntactic one is
an abstract one. The suggestion is that the physical machine provides a semantic
interpretation of the abstract one. 8ut again, a semantic interpretation must provide
us with a notion of correctness and malfunction, and there are compelling
arguments against this that are closely related to the causal theories of function
@R#.'A. This issue will be more carefully eamined in section @R'A where we consider
programming language semantics.
4iven that a semantic account of a language must supply correctness criteria, and
that the term semantics is to have some bite, these are serious obstacles for the
view that implementation is semantic interpretation. There are several phenomena
all rolled into one. If these objections are along the right lines, then the relationship
between the source and target is not semantic interpretation. f course, one may
counter all this by arguing against the correctness requirement for semantic theory.
3.3 Specification and mplementation
!n alternative analysis of implementation is implicit in Turner @#:1&, #:1#A.onsider the case where the data type of nite sets is implemented in the data
types of lists. ach of these structures is governed by a few simple aioms. The
implementation represents nite sets as lists, the union operation on sets as list
concatenation, and equality between sets as etensional equality on lists etc. This is
a mathematical relationship where the aioms for sets act as a specication of the
artifact, which in this case is implemented in the medium of lists. It would appear
that the logical connection between the two is that of specication and artifact. The
mapping does not have to be direct, i.e., there does not have to be a simple
operation to operation correspondence, but the list properties of the implemented
operations must satisfy the given set aioms. In standard mathematical terms, the
list medium must provide a mathematical model @in the sense of model theory, W.6odges #:1&A of the set aioms. The case where one language is implemented in
another is similar, and Geshed out by the semantic denitions of the two languages.
%inally, consider the case where the medium of implementation is a physical device,
e.g., an abstract stac< is implemented as a physical one. nce again the abstract
stac< must provide the correctness criteria for the physical device. This is what
happens in practice. We chec< that the physical operations satisfy the abstract
demands given by the aioms for stac<s. There are issues here that have to do with
the adequacy of this notion of correctness. We shall discuss these when we more
carefully consider the computer science notion of correctness @R0.'A.
If this analysis is along the right lines, implementation is best described as a relation
between specication and artifact. Implementation is not semantic interpretationF
indeed, it requires an independent semantic account in order to formulate a notion
of implementation correctness. $o what is ta<en to be semantic interpretation incomputer science(
4. Semantics
6ow is a semantic account of a language to be given( What are the main
conceptual issues that surround the semantic enterprise( There are many diDerent
semantic candidates in the literature @4ordon 1727F 4unter 177#F %ernandeC #::'F
/ilne and $trachey 1720A. ne of the most important distinctions centers upon the
diDerence between operational and denotational semantics @Turner #::2F White
#::&A.
4.1 T#o $inds of Semantic Theory
perational semantics began life with +andin @170'A. In its logical guise @%ernandeC
#::'A it provides a mechanism of evaluation where, in its simplest form, the
evaluation relation is represented as follows.
P c
This epresses the idea that the program * converges to the canonical form given
by c. This is usually called big step semantics. It is normally given in terms of rulesthat provide the evaluation of a comple program in terms of the evaluation of its
parts. %or eample, a simple rule for sequencing @UA would ta<e the form
P c Qd
P Qcd
These canonical or normal forms are other terms in the programming language
which cannot be further reduced by the given rules. 8ut they are terms of the
language. %or this reason, this operational approach is often said to be
unsatisfactory. !ccording to this criticism, at some point in the interpretation
process, the semantics for a formal language must be mathematical.
We can apparently get quite a long way epounding the properties of a languagewith purely syntactic rules and transformationsQ ne such language is the +ambda
alculus and, as we shall see, it can be presented solely as a formal system with
syntactic conversion rules Q 8ut we must remember that when wor<ing li<e this all
we are doing is manipulating symbols9we have no idea at all of what we are tal<ing
about. To solve any real problem, we must give some semantic interpretation. We
must say, for eample, Vthese symbols represent the integers. @$toy 1722> 7A
In contrast, operational semantics is ta<en to be syntactic. In particular, even if one
of them is in canonical form, the relation *c relates syntactic objects. This does not
get at what we are tal<ing about. Bnless the constants of the language have
themselves an independently given mathematical meaning, at no point in this
process do we reach semantic bedroc<> we are just reducing one syntactic object to
another, and this does not yield a normative semantics. This leads to the demandfor a more mathematical approach.
!pparently, programming languages refer to @or are notations forA abstract
mathematical objects not syntactic ones @$trachey #:::F /c4ettric< 173:F $toy
1722A. In particular, denotational semantics provides, for each syntactic object *, a
mathematical one. /oreover, it generally does this in a compositional way> comple
programs have their denotations ed in terms of the denotations of their syntactic
parts. These mathematical objects might be set theoretic, category theoretic or
type theoretic. 8ut whichever method is chosen, programs are ta<en to refer to
abstract mathematical things. 6owever, this position relies on a clear distinction
between syntactic and mathematical objects.
4.2 Pro%rammin% &an%ua%es as A'iomatic Theories
ne way of addressing this is via the observation that mathematical theories such
as set theory and category theory are aiomatic theories. !nd it is this that ma<es
them mathematical. This is implicit in the modern aiomatic treatment of
mathematics encouraged by @8ourba<i 1703A and championed by 6ilbert. The
following is from 6ilbertKs letter to %rege of "ecember #7, 1377 @%rege 173:> ':A.
In my opinion, a concept can be ed logically only by its relations to other
concepts. These relations, formulated in certain statements, I call aioms, thus
arriving at the view that aioms @perhaps together with propositions assigningnames to conceptsA are the denitions of the concepts. I did not thin< up this view
because I had nothing better to do, but I found myself forced into it by the
requirements of strictness in logical inference and in the logical construction of a
theory. I have become convinced that the more subtle parts of mathematics Q can
be treated with certainty only in this wayF otherwise one is going around in a
circleQ.. LIMt is surely obvious that every theory is only a scaDolding or schema of
concepts together with their necessary relations to one another, and that the basic
elements can be thought of in any way one li<es. If in spea<ing of my points I thin<
of some system of things, e.g., the system> love, law, chimney9sweep Q and then
assume all my aioms as relations between these things, then my propositions, e.g.,
*ythagorasK theorem, are also valid for these things. In other words> any theory canalways be applied to innitely many systems of basic elements.
It is worth pointing out that the aiomatic account, as long as it is precise and
supports mathematical reasoning, does not need to be formal. If one accepts this as
a necessary condition for mathematical status, does it rule out operational
accounts( *rima facie it would seem so. !pparently, programs are reduced to
canonical constants with no aiomatic denitions. 8ut Turner @#::7b, #:1:A argues
this is to loo< in the wrong place for the aiomatiCation> the latter resides not in the
interpreting constants but in the rules of evaluation i.e., in the theory of reduction
given by the aiomatic relation .
If this is right, given that both dene matters aiomatically, as long as they agree, it
should not matter which we ta<e to dene the language as a formal mathematical
theory. Bnfortunately, they donKt always agree> the notion of equality provided by
the operational account, although preserved by the denotationalone, is often morene grained. This has led to very special forms of denotational semantics based
upon games @!brams<y and /cus<er 177-F !brams<y et al. 177'A. 6owever, it is
clear that practitioners ta<e the operational account as fundamental, and this is
witnessed by the fact that they see< to devise denotational accounts that are in
agreement with the operational ones.
5ot only is there no metaphysical diDerence between the set theoretic account and
the operational one, but the latter is ta<en to be the denitive one. This view of
programming languages is the perspective of theoretical computer science>
programming languages, via their operational denitions, are mathematical theories
of computation.6owever, programming languages are very combinatorial in nature. They are
wor<ing tools not elegant mathematical theoriesF it is very hard to eplore them
mathematically. "oes this prevent them from being mathematical theories( There
has been very little discussion of this issue in the literature Turner @#:1:A and
$trachey @#:::A are eceptions. n the face of it, $trachey sees them as
mathematical objects pure and simple. Turner is a little more cautious and argues
that actual programming languages, while often too comple to be eplored as
mathematical theories, contain a core theory of computation which may be
conservatively etended to the full language.
4.3 The mplementation of Pro%rammin% &an%ua%es
6owever, Turner @#:1&A further argues that programming languages, even at their
core, are not just mathematical objects. 6e argues that they are best
conceptualiCed as technical artifacts. While their aiomatic denition provides their
function, they also require an implementation. In the language of technical artifacts,
a structural description of the language must say how this is to be achieved> it must
spell out how the constructs of the language are to be implemented. To illustrate
the simplest case, consider the assignment instruction.
x $) E
! physical implementation might ta<e the following form.
*hysically compute the value of .
*lace the @physical to<en forA the value of in the physical location named F any
eisting to<en of value to be replaced.
This is a description of how assignment is to be physically realiCed. It is a physical
description of the process of evaluation. f course, a complete description will spell
out more, but presumably not what the actual machine is made ofF one assumes
that this would be part of the structural description of the underlying computer, the
medium of implementation. The tas< of the structural description is only to describe
the process of implementation on a family of similarly structured physical machines.
8uilding on this, we stipulate how the comple constructs of the language are to be
implemented. %or eample, to eecute commands in sequence we could add aphysical stac< that arranges them for processing in sequence. f course, matters
are seldom this straightforward. onstructs such as iteration and recursion require
more sophisticated treatment. Indeed, interpretation and compilation may involve
many layers and processes. 6owever, in the end there must be some interpretation
into the medium of a physical machine. Turner @#:1&A concludes that thing that is a
programming language is a comple pac<age of synta?semantics @functionA
together with the implementation as structure.
$ome have suggested that a physical implementation actually denes the
semantics of the language. Indeed, this is a common perspective in the philosophy
of computer science literature. We have already seen that ;apaport @1777A sees
implementation as a semantic interpretation. %etCer @1733A observes that programshave a diDerent semantic signicance to theorems. In particular, he asserts>
Qprograms are supposed to possess a semantic signicance that theorems seem to
lac<. %or the sequences of lines that compose a program are intended to stand for
operations and procedures that can be performed by a machine, whereas the
sequences of lines that constitute a proof do not. @%etCer 1733> 1:-7A
This seems to say that the physical properties of the implementation contribute to
the meaning of programs written in the language. olburn @#:::A is more eplicit
when he writes that the simple assignment statement ! >X 1&Y2' is semantically
ambiguous between something li<e the abstract account we have given, and the
physical one given as>
physical memory location ! receives the value of physically computing 1& times 2'.
@olburn #:::> 1&'A
The phrase physically computing seems to imply that what the physical machine
actually does is semantically signicant i.e., what it actually does determines or
contributes to the meaning of assignment. Is this to be ta<en to imply that to
what assignment means we have to carry out a physical computation( 6owever, if
an actual physical machine is ta<en to contribute in any way to the meaning of the
constructs of the language, then their meaning is dependent upon the
contingencies of the physical device. In particular, the meaning of the simple
assignment statement may well vary with the physical state of the device and withcontingencies that have nothing to with the semantics of the language, e.g., power
cuts. Bnder this interpretation, multiplication does not mean multiplication but
rather what the physical machine actually does when it simulates multiplication.
This criticism parallels that for causal theories of function @R#.'A.
The nature of programs has been the subject of a good amount of philosophical and
legal reGection. What <inds of things are they( !re they mathematical?symbolic
objects or concrete physical things( Indeed, the legal literature even contains a
suggestion that programs constitute a new <ind of @legalA entity.
The eact nature of computer programs is di=cult to determine. n the one hand,
they are related to technological matters. n the other hand, they can hardly becompared to the usual type of inventions. They involve neither processes of a
physical nature, nor physical products, but rather methods of organiCation and
administration. They are thus reminiscent of literary wor<s even though they are
addressed to machines. 5either industrial property law nor copyright law in their
traditional roles seems to be the appropriate instrument for the protection of
programs, because both protections were designed for and used to protect very
diDerent types of creations. The unique nature of the computer program has led to
broad support for the creation of sui generis legislation. @+oewenheim 1737> 1A
This highlights the curious legal status of programs. Indeed, it raises tric<y
ontological questions about the nature of programs and software> they appear to beabstract, even mathematical objects with a comple structure, and yet they are
aimed at physical devices. In this section we eamine some of the philosophical
issues that have arisen regarding the nature of programs and software. $ome of
them have legal origins and potentially legal consequences.
(.1 Pro%rams as *athematical )b+ects
What is the content of the claim that programs are mathematical objects( In the
legal literature the debate seems to centre on the notion that programs are
symbolic objects that can be formally manipulated @4ro<law #:11, #:1#Esee ther
Internet ;esourcesA. Indeed, there is a branch of theoretical computer science calledformal language theory that treats grammars as objects of mathematical study
@6opcroft and Bllman 1707A. While this does give some substance to the claim, this
is not the most important sense in which programs are mathematical. This pertains
to their semantics, where programming languages are ta<en to be aiomatic
theories @R'.#A. This perspective locates programs as elements in a theory of
computation @Turner #::2, #:1:A.
8ut no matter in what sense programs are ta<en to be mathematical objects, there
are legal ramications. If programs and software are ta<en to be abstract
mathematical things, then they cannot easily be governed by copyright. 5ormally,
copyright law ecludes pure abstract ideas. /ooers @172-A attempts to meet this
objection by drawing a distinction between an idea that is not copyrightable, and acopyrightable epression of an idea.
Where does the Vepression leave oD, and the Videa ta<e over( The best insight
into this matter comes from discussions of copyright as applied to novels and
dramatic productions. In these, Vepression is considered to include the choice of
incident, the personalities and development of character, the choice of names, the
elaboration of the plot, the choice of locale, and the many other minor details and
gimmic<s used to build the story. In other words, Vepression is considered to
include not only the mar<s, words, sentences, and so on in the wor<, but also all
these other details or structures as they aggregate into larger and larger units to
ma<e up the epression of the entire story Q In other words, after the bare abstract
Videa has been chosen @e.g., boy meets girl, boy loses girl, boy wins girlA, the
Vepression to which copyright applies covers the remaining elements of originalchoice and artistry which are supplied by the author in order for him to develop,
epress, and convey his version of the bare idea. @/ooers 172-> -:A
6owever, in the case of programs, is it clear how to mar< the boundary between an
idea and an epression of it( Is the idea of a program contained in its semantics or
its specication( 6ow is it related to the algorithm?program distinction(
(.2 Pro%rams as Technical Artifacts
While agreeing that programs have an abstract guise, much of the philosophical
literature @e.g., olburn #:::F /oor 1723A has it that they also possess a concrete
physical manifestation that facilitates their use as the cause of computations inphysical machines. %or eample, /oor observes>
It is important to remember that computer programs can be understood on the
physical level as well as the symbolic level. The programming of early digital
computers was commonly done by plugging in wires and throwing switches. $ome
analogue computers are still programmed in this way. The resulting programs are
clearly as physical and as much a part of the computer system as any other part.
Today digital machines usually store a program internally to speed up the eecution
of the program. ! program in such a form is certainly physical and part of the
computer system. @/oor 1723> #1-A
The following is of more recent origin, and more eplicitly articulates the duality
thesis in its claim that software has both abstract and physical guises.
/any philosophers and computer scientists share the intuition that software has a
dual nature @/oor 1723, olburn #:::A. It appears that software is both an
algorithm, a set of instructions, and a concrete object or a physical causal process.
@Irma< #:1#> &A
$ome shadow of thus duality emerges in the legal literature> to be subject to patent,
programs must have some technical eDect.
In this contet, the ourt described a Vtechnical nature as an Vinstruction to a
systematic acting by utiliCing controllable natural forces to achieve a causallypredictable result. In other words, the <ey element which characteriCes the
technical nature of an invention is the control of natural forces to achieve a
predicted result. @+oewenheim 1737> #A
!pparently, to qualify for a patent, a computer program cannot be simply an
abstract thingF it must also utiliCe controllable forces of nature to achieve
predictable results. It must cause a computer to do something li<e display items on
screen, store a particular pattern in a memory, or activate a peripheral device> it
must provide a technical eDect. This is in line with the notion that programs are
technical artifacts. 6owever, the legal situation is very far from being all moonlight
and roses. The debate is ongoing @;apaport #:1:F 4ro<law #:11, #:1#Esee ther
Internet ;esourcesA.
(.3 Abstract and Concrete
!nyone persuaded by the abstract?physical duality for programs is under an
obligation to say something about the relationship between these two forms of
eistence. This is the major philosophical concern and parallels the question for
technical artifacts in general.
ne immediate suggestion is that programs, as tetual objects, cause mechanical
processes. The idea seems to be that somehow the tetual object physically causes
the mechanical process. olburn @#:::, 1777A denies that the symbolic tet itself
has any causal eDectF it is its physical manifestation, the thing on the dis<, which
has such an eDect. %or him, software is a concrete abstraction that has a medium of description @the tet, the abstractionA and a medium of eecution @e.g., a concrete
implementation in semiconductorsA. The duality is unpac<ed in a way that is parallel
to that found in the philosophy of mind @see the entry on dualismA, where the
physical device is ta<en as a semantic interpretation of the abstract one. This is
close to the perspective of ;apaport @1777A. 6owever, we have already alluded to
problems with this approach @R&.&A.
! slightly diDerent account can be found in %etCer @1733A. 6e suggests that abstract
programs are something li<e scientic theories> a program is to be seen as a theory
of its physical implementationEprograms as causal models. In particular, the simple
assignment statement and its semantics is a theory about a physical store and howit behaves. If this is right, and a program turns out not to be an accurate description
of the physical device that is its implementation, the program must be changed> if
the theory which is enshrined in the program does not t the physical device, being
a theory, it should be changed. 8ut this does not seem to be what happens in
practice. While the program may have to be changed, this is not instigated by any
lac< of accord with its physical realiCation, but by an independent abstract
semantics for assignment. If this is correct, the abstract semantics appears not to
be a theory of its concrete implementation.
The alternative picture has it that the abstract program @determined by its
semanticsA provides the function of the artifact, and the physical artifact, or rather
its description, provides its structure. It is the function of the program, epressed inits semantics, that es the physical implementation and provides the criteria of
correctness and malfunction. *rograms as computational artifacts have both an
abstract aspect that somehow es what they do, and a physical aspect that
omputer programming is an eact science in that all the properties of a program
and all the consequences of eecuting it in any given environment can, in principle,
be found out from the tet of the program itself by means of purely deductive
reasoning. @6oare 1707> -20A
onsider our specication of a square root function. What does it mean for a
program * to satisfy it( *resumably, relative to its abstract semantics, everyprogram @*A, carves out a relationship ;* between its input and output, its
etension. The correctness condition insists that this relation satises the above
specication, i.e.,
(+'\ x$ Real . \ y$ Real ] xZ * ( R P ( x, y' y[ y ) x and yZ *'
This demands that the abstract program, determined by the semantic interpretation
of its language, satises the specication. The statement @A is a mathematical
assertion between two abstract objects and so, in principle, the correctness maybe
established mathematically. ! mathematical relationship of this <ind is surely what
Tony 6oare has in mind, and in terms of the abstract guise of the program, there islittle to disagree with. 6owever, there are several concerns here. ne has to do with
the compleity of modern software @the compleity challengeA, and the other the
nature of physical correctness @the empirical challengeA.
.2 The Comple'ity Challen%e
*rogrammers are always surrounded by compleityF we cannot avoid it. ur
applications are comple because we are ambitious to use our computers in ever
more sophisticated ways. *rogramming is comple because of the large number of
conGicting objectives for each of our programming projects. If our basic tool, the
language in which we design and code our programs, is also complicated, thelanguage itself becomes part of the problem rather than part of its solution. @6oare
1731> 1:A
Within the appropriate mathematical framewor< proving the correctness of any
linguistic program, relative to its specication, is theoretically possible. 6owever,
real software is comple. In such cases proving correctness might be practically
infeasible. ne might attempt to gain some ground by advocating that classical
correctness proofs should be carried out by a theorem prover, or at least one should
be employed somewhere in the process. 6owever, the latter must itself be proven
correct. While this may reduce the correctness problem to that of a single program,
it still means that we are left with the correctness problem for a large program.
/oreover, in itself this does not completely solve the problem. %or both theoretical
and practical reasons, in practice, human involvement is not completely eliminated.
In most cases proofs are constructed by hand with the aid of interactive proof
systems. ven so, a rigorous proof of correctness is rarely forthcoming. ne might
only require that individual correctness proofs be chec<ed by a computer rather
than a human. 8ut of course the proof9chec<er is itself in need of chec<ing.
!r<oudas and 8ringsjord @#::2A argue that since there is only one correctness proof
that needs to be chec<ed, namely that of the proof chec<er itself, then the
possibility of mista<es is signicantly reduced.
This is very much a practical issue. 6owever, there is a deeper conceptual one. !re
proofs of program correctness genuine mathematical proofs, i.e., are such proofs on
a par with standard mathematical ones( The authors of @"e /illo et al. 1727A claim
that correctness proofs are unli<e proofs in mathematics. The latter are conceptuallyinteresting, compelling and attract the attention of other mathematicians who want
to study and build upon them. This argument parallels the graspability arguments
made in the philosophy of mathematics. *roofs that are long, cumbersome and
uninteresting cannot be the bearers of the <ind of certainty that is attributed to
standard mathematical proofs. The nature of the <nowledge obtained from
correctness proofs is said to be diDerent to the <nowledge that may be gleaned
from standard proofs in mathematics. In order to be ta<en in, proofs must be
graspable. Indeed, Wittgenstein would have it that proofs that are not graspable
cannot act as norms, and so are not mathematical proofs @Wittgenstein 17-0A.
/athematical proofs such as the proof of 4^delKs incompleteness theorem are alsolong and complicated. 8ut they can be grasped. What renders such complicated
proofs transparent, interesting and graspable involves the use of modularity
techniques @e.g., lemmasA, and the use of abstraction in the act of mathematical
creation. The introduction of new concepts enables a proof to be constructed
gradually, thereby ma<ing the proofs surveyable. /athematics progresses by
inventing new mathematical concepts that facilitate the construction of proofs that
would be far more comple and even impossible without them. ! very elementary
eample concerns the eponent notation. This ma<es it possible to etend
computation beyond the compleity of multiplication, and to argue about the
results. !t the other etreme, the invention of category theory facilitated the
statement and proof of very general results about algebraic structures thatautomatically apply to a whole range of such. /athematics is not just about proofF it
also involves the abstraction and creation of new concepts and notation. In contrast,
formal correctness proofs do not seem to involve the creation of new concepts and
notations. While computer science does involve abstraction, it is not quite in the
same way.
ne way of addressing the compleity problem is to change the nature of the game.
The classical notion of correctness lin<s the formal specication of programs to its
formal semantic representation. It is at one end of the mathematical spectrum.
6owever, chains of specication?artifact pairings, positioned at varying degrees of
abstraction, are governed by diDerent notions of correctness. %or eample, in the
object oriented approach, the connection between a B/+ specication and a Oavaprogram is little more than type chec<ing. The correctness criteria involve structural
similarities and identities @4amma et al. 177'A. 6ere we do not demand that one
innite mathematical relation is etensionally governed by another. !t higher levels
of abstraction, we may have only connections of structure. These are still
mathematical relationships. 6owever, such methods, while they involve less wor<,
and may even be automatically veried, establish much less.
The notion of program verication appears to trade upon an equivocation.
!lgorithms, as logical structures, are appropriate subjects for deductive verication.
*rograms, as causal models of those structures, are not. The success of program
verication as a generally applicable and completely reliable method forguaranteeing program performance is not even a theoretical possibility. @%etCer
1733> 1A
In fact this issue is alluded to by 6oare in the very tet that %etCer employs to
characteriCe 6oareKs mathematical stance on correctness.
When the correctness of a program, its compiler, and the hardware of the computer
have all been established with mathematical certainty, it will be possible to place
great reliance on the results of the program, and predict their properties with a
condence limited only by the reliability of the electronics. @6oare 1707> -27A
!ll seemed to be agreed that computational systems are at bottom physical
systems, and some unpredictable behavior may arise because of the causal
connections. Indeed, even when theorem provers and the proof chec<ers are used,
the results still only yield empirical <nowledge. ! proof chec<er is a program running
on a physical machine. It is a program that has been implemented and its results
depend upon a physical computation. onsequently, at some level, we shall need to
show that some physical machine operations meet their specication. Testing and
verication seems only to yield empirical evidence. Indeed, the compleity of
program proving has led programmers to ta<e physical testing to be evidence that
the abstract program meets its specication. 6ere the assumption is that the
underlying implementation is correct. 8ut prima facie, it is only empirical evidence.
In apparent contrast, 8urge @1733A argues that <nowledge of such computer proofscan be ta<en as a priori <nowledge. !ccording to 8urge, a priori <nowledge does not
depend for its justication on any sensory eperience. 6owever, he allows that a
priori <nowledge may depend for its possibility on sensory eperience e.g.,
<nowledge that red is a color may be a priori even though having this <nowledge
requires having sensory eperience of red in order to have the concepts required to
even formulate the idea. If correct, this closes the gap between a priori and a
posteriori claims about computer assisted correctness proofs, but only by redrawing
the boundary between a priori and a posteriori <nowledge so that some empirical
assertions can fall into the former category. %or more discussion on the nature of the
use of computers in mathematical proofs see 6ales #::3F 6arrison #::3F TymocC<o
1727, 173:.
Bnfortunately, practice often does not even get this far. 4enerally, software
engineers do not construct classical correctness proofs by hand or even
automatically. Testing of software against its specication on suites of test cases is
the best that is normally achieved. f course this never yields correctness in the
mathematical sense. Test cases can never be ehaustive @"ij<stra 172'A.
%urthermore, there is a hidden assumption that the underlying implementation is
correct> at best, these empirical methods tell us something about the whole system.
Indeed, the siCe of the state space of a system may be so large and comple that
even direct testing is infeasible. In practice, the construction of mathematical
models that approimate the behavior of comple systems is the best we can do.
The whole correctness debate carried out in the forum of the !/ @e.g., !shenhurst
1737F Technical orrespondence 1737A is put into some perspective when programsare considered as technical artifacts. 8ut this leaves one nal topic> when we have
reached physical structure, what notion of correctness operates(
.4 Physical Correctness
What is it for a physical device to meet its specication( What is it for it to be a
correct physical implementation( The starting point for much contemporary analysis
is often referred to as the simple mapping account.
!ccording to the simple mapping account, a physical system $ performs as a correct
implementation of an abstract specication just in case @iA there is a mappingfrom the states ascribed to $ by a physical description to the states dened by the
abstract specication , such that @iiA the state transitions between the physical
states mirror the state transitions between the abstract states. lause @iiA requires
that for any abstract state transition of the form s1 _ s#, if the system is in the
physical state that maps onto s1, it then goes into the physical state that maps onto
s#.
To illustrate what the simple mapping account amounts to we consider the eample
of our abstract machine @R#.1A where we employ an instance of the machine that
has only two locations l and r, and two possible values : and 1. $ubsequently, we
have only four possible states @:,:A, @:,1A,@1,1A and @1,:A. The computation table for
the update operation may be easily computed by hand, and ta<es the form of a
table with input?output pairings. %or eample, Bpdate@r,1A sends the state @:,:A the
state @:,1A. The simple mapping account only demands that the physical system can
be mapped onto the abstract one in such a way that the abstract state transitions
are duplicated in the physical version.
Bnfortunately, such a device is easy to come by> almost anything with enough
things to play the role of the physical states will satisfy this quite wea< demand of
what it is to be an implementation. %or eample, any collection of colored stones
arranged as the update table will be ta<en to implement the table. $/! only
demands etensional agreement. It is a de9facto demand. This leads to a form of
pancomputationalism where almost any physical system implements anycomputation.
The danger of pancomputationalism has driven some authors @". O. halmers 1770F
gan 177#F $preva< #:1#A to attempt to provide an account of implementation that
somehow restricts the class of possible interpretations. In particular, certain authors
@". O. halmers 1770F opeland 1770A see< to impose causal constraints on such
interpretations. ne suggestion is that we replace the material conditional @if the
system is in the physical state $` QA by a counterfactual one. In contrast, the
semantic account insists that a computation must be associated with a semantic
aspect which species what the computation is to achieve @$preva< #:1#A. %or
eample, a physical device could be interpreted as an and gate or an or gate. It
would seem to depend upon what we ta<e to be the denition of the device. Without
such there is no way of ing what the artifact is. The syntactic account demandsthat only physical states that qualify as syntactic may be mapped onto
computational descriptions, thereby qualifying as computational states. If a state
lac<s syntactic structure, it is not computational. f course, what remains to be
seen is what counts as a syntactic state. ! good overview can be found in the entry
on computation in physical systems.
Turner @#:1#A argues that abstract structure and physical structure are lin<ed, not
just by being in agreement, but also by the intention to ta<e the former as having
normative governance over the latter. n this account, computations are technical
artifacts whose function is ed by an abstract specication. This relationship is
neither that of theory to physical object nor that of syntactic thing to semantic
interpretation.
8ut there is an ambiguity here that is reGected in the debate between those who
argue for semantic interpretation @$preva< #:1#A, and those who argue against it
@*iccinini #::3A. onsider programs. What is the function of a program( Is it ed by
its semantic interpretation or is it ed by its specication. The ambiguity here
concerns the function of a program as part of a programming language or its role as
part of a larger system. !s a program in a language, it is ed by the semantics of
the language as a whole. 6owever, to use a program as part of a larger system, one
needs only <now what it does. The function of the program, as part of a larger
system, is given by its specication. When a computation is pic<ed out by a
specication, eactly how the program achieves its specication is irrelevant to thesystem designer. The specication acts as an interface, and the level of abstraction
employed by the system designer is central.
0. Pro%rammin%
-lthough programming is one of the core activities of computer science, there has been littlesustained philosophical debate about its nature. hat there has been revolves around thefollowing /uestion$ what kind of activity is programming0 Is it mathematics, engineering,science or art (1nuth !23'0 4his debate is about the methodology of computer science ratherthan the ontological status of programs, but inevitably the latter will leak into the discussion.
0.1 Pro%rammin% as a *athematical Actiity
5ne very influential computer scientist claimed that programming is, or should be,methodologically a mathematical activity. 4his is aimed at the actual process of programconstruction. 6oare suggests that programs can be derived from their specifications in amathematically precise way using program transformations that are based upon algebraic laws.
I hold the opinion that the construction of computer programs is a mathematical activity like thesolution of differential e/uations, that programs can be derived from their specifications throughmathematical insight, calculation, and proof, using algebraic laws as simple and elegant as thoseof elementary arithmetic (6oare !7!$ %27'.
4his can also be seen as an alternative approach to the correctness problem$ programs arederived from their specifications by laws that preserve correctness. 8organ (!!3' develops thetransformational approach for imperative style languages. 4he functional style has also (6enson!"2' embraced this style of transformational programming. 8artin9:;f (!"&' advocated theuse of constructive mathematics as a means of deriving programs from (constructive' e<istence proofs. 6owever, in the contemporary scene, there is little evidence that real software isdeveloped in this way. Systematic program development from specifications is still an activeresearch topic, but the comple<ity issue is still with us.
4he position of =ijkstra (!23' is somewhat softer. 6e only seems to be suggesting that programming involves rigorous reasoning. 6ere at least, he is not advocating that programs can
be mathematically developed from specifications.
ith respect to mathematics I believe, however, that most of us can heartily agree upon thefollowing characteristics of most mathematical work$ . compared with other fields ofintellectual activity, mathematical assertions tend to be unusually precise. &. 8athematicalassertions tend to be general in the sense that they are applicable to a large (often infinite' classof instances. #. 8athematics embodies a discipline of reasoning allowing such assertions to bemade with an unusually high confidence level.
4he mathematical method derives its power from the combination of all these characteristics>conversely, when an intellectual activity displays these three characteristics to a strong degree, I
feel justified in calling it ?an activity of mathematical nature@, independent of the /uestionwhether its subject matter is familiar to most mathematicians. (=ijkstra !23$ &'
4his claims that the development of programs and software involves precise reasoning, presumably about the underlying type structure and control mechanisms. 4here is little doubt thatsomething like this is true. hile programmers seldom prove rigorous theorems about software,this obviously does not mean that they do not reason when designing and testing programs.Arogramming is a precise intellectual activity that involves precise reasoning about the effects oftheir programming constructs on some underlying machine. 4his is a fairly minimalistic claimthat it is hard to dispute.
But even if we accept this, we are not told what kind of mathematical activity programming is.e are only told it involves rigorous reasoning about some kind of formal objects. 6owever, onthe assumption that programming languages are a<iomatic theories of computation, there is asimple characteriCation. hen glossed with the perspective of (D3.&', programs are definitionswithin the mathematical theory of the programming language. 4his does not argue for any kindof methodological stance, only that programs are definitions and programming is the activity ofcreating them> programming is a definitional enterprise. If one accepts this, there is a logical
uniformity about specification and programming$ both specifications and programs aredefinitions inside their containing mathematical theories.
0.2 Pro%rammin% as /n%ineerin% Desi%n
6owever, the invention of software engineering (Summerville &*&> Eliet &**"' moved the goal posts. hile formal methods form a part of many methodologies, modern software developmentuses a rich mi<ture of methods and techni/ues. Arogramming in the raw involves theconstruction of technical artifacts, not mathematical objects. In this more complete picture, programming is an engineering activity.
4here are some general design principles that do have a conceptual ring about them. 4hemovement of structured programming (=ijkstra !2*' argues that programs should beconstructed in a transparent way that is in some sense compositional. 5n this basis users wereurged to avoid the use of goto statements and unstructured jumps. 4his had some impact upon programming language design. 4he 4uring award lecture (Floyd !2!' contains some further
reflections on structured programming and its impact upon software development. In a moremodern form, encapsulation (8itchell &**#' tries to ensure that programs are self9containedunits with transparent and self9contained functional specificationsavoid leaky modules thatmake reference to lower levels of abstraction.
4hese are principles of design. But these notions have yet to be subject to much philosophicalanalysis. Indeed, the whole of the philosophy of engineering design, with all its conceptual/uestions and apparatus, for e<ample as outlined in 1roes (&*&', has yet to be applied tocomputational artifacts.
0.3 Pro%rammin% as Theory Construction
Some claim that software development is a scientific activity. Indeed, there is a hint of such a perspective in many of the 4uring award lectures (-+8 &*#see 5ther Internet Gesources'where one can find many variations on the more general claim that computer science is ascientific activity. 5ne folklore claim has it that programs act as scientific theories or models.6owever, such theories are always up for revision> they provide defeasible knowledge(Gosenberg &***> -. F. +halmers !!!'. 8ore importantly, when there is a mismatch betweenthe theory and the natural world, the theories may have to be given up in the light ofe<perimentation. Arogram verification certainly fits the testing and verifying methodology. But itis not clear that its purpose is the verification of a model or theory. hen a program is tested, itis tested against a specification not for its agreement with the physical world. It would seem that
programs, in the primary role, are not intended to be scientific theories of anything> they functionas artifacts.
8oreover, while programs may themselves function as specifications, whereas scientific theoriesare concerned with natural objects and phenomena, specifications are concerned withintentionally produced things. -nd, as we have already observed, (D3.&', in regard to theirunderlying logic, there appears to be a fundamental difference between specifications andtheories.
6owever, there is a very specific argument that needs consideration. 4he paper (-ngius &*#'contains an argument for the claim that modern software development is partly a scientificactivity. 4his argument is based on the observation that software testing and verification employmodel based techni/ues> the software system is modeled because of the comple<ity of the realthing. 6ere there is a direct analogy with scientific models. If the model gets things wrong i.e.,
does not capture the system, then it will be modified or replaced. 4his process resemblesstandard model construction in science (Frigg and 6artmann &*&'. 6owever, it would seem thatthe purpose here is different. 4he function of the model is to stand pro<y for the system in the process of verification. e are not trying to model the system as a natural thing but as a technicalartifact. 4he methodology may be similar, but we are dealing with a designed artifact. 4henormative role of the specification is still in force, e<cept that now the specification hasnormative force over the system indirectly via the model. 5n the face of it, because computerscientists build mathematical models of comple< computational systems, it does not mean thatthey are engaged in a scientific activity in the same way that physicists are.
+omputer science… differs from physics in that it is not actually a science. It does not study
natural objects. Heither is it, as you might think, mathematics> although it does use mathematicalreasoning pretty e<tensively. Gather, computer science is like engineering> it is all about gettingsomething to do something, rather than just dealing with abstractions, as in the pre9Smithgeology. (Feynman &*** !"3J!"7K$ "'
. Abstraction
-bstraction facilitates computer science. ithout it we would not have progressed from the programming of numerical algorithms to the software sophistication of air traffic controlsystems, interactive proof development frameworks, and computer games. It is manifested in therich type structure of contemporary programming and specification languages, and underpins the
design of these languages with their built9in mechanisms of abstraction. It has driven theinvention of notions such as polymorphism, data abstraction, classes, schema, design patterns,and inheritance. But what is the nature of abstraction in computer science0 Is there just one formof it0 Is it the same notion that we find in mathematics0
.1 The eneral ature of Abstraction
4his is how Skemp (!"2' describes abstraction. 6is conception begins with similarityrecognition and results in the embodiment of this similarity in a new concept.
-bstracting is an activity by which we become aware of similarities … among our e<periences.
+lassifying means collecting together our e<periences on the basis of these similarities. -nabstraction is some kind of lasting change, the result of abstracting, which enables us torecogniCe new e<periences as having the similarities of an already formed class…. 4o distinguish between abstracting as an activity and abstraction as its end9product, we shall call the latter aconcept. (Skemp !"2$ %'
In the opening paragraph of his lectures on data structuring (6oare !2#$ "#', the computerscientist 4ony 6oare describes abstraction in much the same way.
-bstraction arises from recognition of similarities between certain objects, situations, or processes in the real world, and the decision to concentrate upon those similarities and to ignorefor the time being the differences.
Such abstraction involves ignoring concrete features, the structural aspects of the device or
process. From this voluntary ignorance a new concept emerges. 4his has it that abstraction is amental process. Lnfortunately, so conceived, it employs a much criticiCed perspective in the philosophy of mind (see the entry on abstract objects'.
- related approach is more logical in nature. +rispin right (!"#' and Bob 6ale (!"2' havedeveloped an account of abstraction that emanates from Frege. +onsider the following equations.
• 4he direction of a ) the direction of b if and only if a is parallel to b.
• 4he number of F s ) the number of Gs if and only if there are just as many F s as Gs.
M<pressions such as the direction of a line or the number of form the basis of abstraction> theyare abstraction principles. 4hey appear to hold in virtue of the meaning of the e<pressions on theright hands sides$ on the face of it, mastery of the concept of a direction presupposes mastery ofthe concept of parallelism, but not vice versa. 4his is discussed in more detail in the entry onabstract objects. 6owever, the ade/uacy of this account to deal with the abstraction mechanismsof computer science has not been investigated.
.2 Abstraction in Computer Science
+omputer science abstraction takes many different forms. e shall not attempt to describe thesein any systematic way here. 6owever, Noguen (NoguenOBurstall !"%' describes some of this
variety of which the following e<amples are instances.
5ne kind involves the idea of repeated code$ a program te<t, possibly with a parameter, is givena name ( procedural abstraction'. In SkempPs terms, the procedure brings a new concept intoe<istence, where the similarity of structure is the common code. Formally, this is the abstractionof the :ambda calculus (see the entry on the lambda calculus'. 4he parameter might even be atype, and this leads to the various mechanisms of polymorphism, which may be formaliCed inmathematical theories such as the second order :ambda calculus (6ankin &**3'.
Gecursion is an early e<ample of operation or mechanism abstraction$ it abstracts away from themechanisms of the underlying machine. In turn, this facilitates the solution of comple< problems
without having to be aware of the operations of the machine. For e<ample, recursion isimplemented in devices such as stacks, but in principle the user of recursion does not need toknow this.
4he type structure of a programming or specification language determines the ontology of thelanguage$ the kinds of entity that we have at our disposal for representation and problem solving.4o a large e<tent, types determine the level of abstraction of the language. - rich set of type
constructors provides an e<pressive system of representation. -bstract and recursive types arecommon e<amples.
In object oriented design, patterns (Namma et al. !!3' are abstracted from the commonstructures that are found in software systems. 6ere, abstraction is the means of interfacing$ it
dissociates the implementation an object from its specification. For e<ample, abstract classes actas interfaces by providing nothing but the type structure of its methods.
In addition, in mathematics (8itchelmore and hite &**3', computer science and philosophy(Floridi &**"' there are levels of abstraction. -bstractions in mathematics are piled upon eachother in a never ending search for more and more abstract concepts. :ikewise, computer sciencedeals with the design and construction of artifacts through a comple< process involvingse/uences of artifacts of decreasing levels of abstractness, until one arrives at the actual physicaldevice.
.3 nformation 5idin%
In mathematics, once the abstraction is established, the physical device is left behind. 5n thisaccount, the abstraction is self9contained$ an abstract mathematical object takes its meaning onlyfrom the system within which it is defined. 4he only constraint is that the new objects be relatedto each other in a consistent system which can be operated on without reference to their previousmeaning. Self9containment is paramount. 4here are no leaks. 4his is clearly e<pressed in6ilbertPs view of a<iomatiCation (D%.'.
Some argue that, in this respect at least, abstraction in computer science is fundamentallydifferent to abstraction in mathematics (+olburn O Shute &**2'. 4hey claim that computationalabstraction must leave behind an implementation trace. Information is hidden but not destroyed.
-ny details that are ignored at one level of abstraction (e.g., programmers need not worry aboutthe precise location in memory associated with a particular variable' must not be ignored by oneof the lower levels (e.g., the virtual machine handles all memory allocations'. -t all levels,computational artifacts crucially depend upon the e<istence of an implementation. For e<ample,even though classes hide the implementation details of their methods, e<cept for abstract ones,they must have implementations. 4his is in keeping with the view that computational artifactshave both function and structure$ computational abstractions have both an abstract guise and animplementation.
6owever, matters are not /uite so clean cut. hile it is true that abstraction in mathematicsgenerates objects whose meaning is defined by their relationships, the same is so in computer
science. -bstract notions could not have a normative function unless they had such independentmeanings. 8oreover, certain forms of constructive mathematics resembles computer science inthat there has to be an implementation trace$ one must always be able to recover implementationinformation from proofs by reading between the lines. 5f course, this is not the case for classicalmathematics.
8oreover, many would argue that mathematical abstractions do not completely leave behindtheir physical roots.
5ne aspect of the usefulness of mathematics is the facility with which calculations can be made$Qou do not need to e<change coins to calculate your shopping bill, and you can simulate a rocket journey without ever firing one. Increasingly powerful mathematical theories (not to mention thecomputer' have led to steady gains in efficiency and reliability. But a calculational facility would be useless if the results did not predict reality. Aredictions are successful to the e<tent that
mathematical models appropriate aspects of reality and whether they are appropriate can bevalidated by e<perience. (8itchelmore and hite &**3$ ##*'
6ow is it that the a<iomatic method has been so successful in this way0 4he answer is, in large part, because the a<ioms do indeed capture meaningful and correct patterns. … 4here is nothingto prevent anyone from writing down some arbitrary list of postulates and proceeding to provetheorems from them. But the chance of those theorems having any practical application isK slimindeed. … 8any fundamental mathematical objects (especially the more elementary ones, suchas numbers and their operations' clearly model reality. :ater developments (such ascombinatorics and differential e/uations' are built on these fundamental ideas and so also reflectreality even if indirectly. 6ence all mathematics has some link back to reality. (=evlin !!3$ %3J
%%'
I want to say$ it is essential to mathematics that its signs are also employed in mufti. It is the useoutside mathematics, and so the meaning of the signs, that makes the sign9game intomathematics. Rust as it is not logical in formation either, for me to make a change from oneformation to another (say from one arrangement of chairs to another' if these arrangements havenot a linguistic function apart from this transformation. (ittgenstein !%7$ &7"'
If would appear that the difference between abstraction in computer science and abstraction inmathematics is not so sharp. 6owever, there appears to be an important conceptual difference. If4urner (&*' is right, in computer science, the abstract partner is the dominant one in the
relationship$ it determines correctness. In the case of (applied' mathematics things are reversed$the mathematics is there to model the world, and it must model it accurately. In computerscience, the relationship between the abstraction and its source is the specificationartifactrelationship> in mathematics it is the modeltheory to reality relationship. hen things go wrongthe blame is laid at a different place$ with the artifact in computer science and with the model inmathematics.
6. Computation
4he original motivation for a mathematical analysis of computation came from mathematicallogic. Its origins are to be found in 6ilbertPs /uestion concerning the decidability of predicate
calculus$ could there be an algorithm, a procedure, for deciding of an arbitrary sentence of thelogic whether it was provable (4he Entscheidungsproblem'. In order to address this /uestion, arigorous model of the informal concept of an effective or mechanical method in logic andmathematics was re/uired. Aroviding this is first and foremost a mathematical endeavor$ one hasto develop a mathematical analogue of the informal notion. hat is now taken to be thedefinitive account was given by 4uring (!#7'.
6owever, 4uring was not the first to attempt such a characteriCation. 6istorically, the firstnotions of computability were suggested in the early nineteen thirties.
1leene demonstrated that these two notions were e<tensionally e/uivalent. 4his gave rise to twoe<tensionally e/uivalent versions of +hurchPs thesis$
• 4he computable functions are the general recursive functions.
• 4he computable functions are those computable by :ambda terms.
6owever, N;del was not convinced> he rejected both versions. 6e did not accept that theye<press an intensionally ade/uate notion of a mechanical method. 4hey were e<tensional
characteriCations with little motivational justification. In contrast, 4uringPs proposed class ofdevices, now known as 4uring machines, appeared to capture the informal notion. Furthermore,4uring proved that his machines and the :ambda calculus are e<tensionally e/uivalent. 4his ledto the 4uring version of the thesis, one formulation of which is the following.
4uringPs thesis$:ogical computing machines (4uringPs name for his machines' can do anythingthat could be described as ?rule of thumb@ or ?purely mechanical@.
Mven today, every program written in an e<isting implemented programming language is 4uringcomputable and conversely, all general9purpose programming languages are 4uring complete,
i.e., they contain all the control constructs necessary to simulate a universal 4uring machine. Butwhat is so special about the 4uring proposal0
6.2 The ature of Computation
4uring placed great emphasis on the nature of the basic instructions of a 4uring machine. 4hefollowing prose suggests the instructions can be performed without thought$ atomic operationscan be implemented in machines that do not and cannot know the meaning of their instructions.4his is emphasiCed by many commentators.
Instructions given the computer must be complete and e<plicit, and they must enable it to
proceed step by step without re/uiring that it comprehend the result of any part of the operationsit performs. Such a program of instructions is an algorithm. It can demand any finite number ofmechanical manipulations of numbers, but it cannot ask for judgments about their meaning …-n algorithm is a set of rules or directions for getting a specific output from a specific input. 4hedistinguishing feature of an algorithm is that all vagueness must be eliminated> the rules mustdescribe operations that are so simple and well defined they can be e<ecuted by a machine.(1nuth !22$ 7#'
4he instructions must be complete and e<plicit and the human computer is not re/uired tocomprehend of any part of the basic operations$ they must proceed without any appeal to thesemantics of the operations of the machine.
4he intuitive notion of an algorithm is rather vague. For e<ample, what is a rule0 e would like
the rules to be mechanically interpretable, i.e., such that a machine can understand the rule(instruction' and carry it out. In other words, we need to specify a language for describingalgorithms which is general enough to describe all mechanical procedures and yet simple enoughto be interpreted by a machine…. hat 4uring did was to analyse the human calculating act andarrive at a number of simple operations which are obviously mechanical in nature and yet can beshown to be capable of being combined to perform arbitrarily comple< mechanical operations.(ang !23$ !'
But is there such a thing as an instruction or operation in a programming language that has nomeaning0 Is it possible that we can follow an instruction without making judgments about itsmeaning0 -re these instructions really meaningless0
But given that this is a genuine rule it is anything but meaningless. Nranted, it is so simple thatone can envisage an agent doing it mechanically after a short while, and that is the problem thatwill be looked at last. For the moment we need only see that, however simple this rule might be,it does indeed tell one what to do. (Shanker !"2$ 7#2'
4he point here seems to be that rule following involves judgments about meaning. hileeventually one may be able to perform them without thought , initially, the performer must havetaken in the meaning. 4hey could not have been followed without thought. 4his is at the heart ofthe ittgenstein94uring debate on the nature of computation. In 4uringPs account the normativeaspect of meaning (NlTer and ikforse &**!' is replaced by what appears to be a causal
interpretation of the basic operations. 4his is made e<plicit in the following analysis given byShanker.
4he only way to remove its normative content is to treat it as a description of the causal eventsthat occur in the mindprogram of the computer which trigger off certain reactions. 4hus 4uringintroduced the premise that Uthe behaviour of the computer at any moment is determined by thesymbols which he is observing, and his Vstate of mindV at that momentW (#7K$ #7'. 5n this picture the computerPs Ustate of mindW is the causal intermediary between Uobserved symbolsW andsubse/uent action. (Shanker !"2$ 7#2'
If this is correct, the simple instructions get their content from the impact they have on the
physical device. 5n this view they must act as theories of the underlying physical device. Butthen it would appear that our instructions are not rules with normative force but descriptions ofthe physical device. 4his seems to be in line with +olburn (&***'. 6owever, we have crossed thenormative descriptive divide. 5ur basic operations are no longer rules in any normative sense.
4uring 8achines are 6umans who +alculate (ittgenstein !2% !#!K$ *!7'
Is calculationcomputation something that humans do or something that machines door both0Is it a rule governed mathematical activity or an empirical one0 Is it the rules of addition that provide the correctness criteria for any physical activity that we might wish to call addition, or isit an empirical activity0 If the latter, the evaluation of arithmetic e<pressions is subject to physical interference. Ahysical multiplication may not mean multiplication but rather what the
physical machine actually does when it multiplies. +onse/uently, #X23 might be 7.
4his is a position close to the view that the semantics of a programming language is fi<ed by its physical implementation (D3.#'. 4his treats #X23 as a description of the causal events that occur in the mindprogram of the computer which trigger off certain physical reactions. 4hus 4uringintroduced the premise that
thebehaviour of the computer at any moment is determined by the symbols which he is observingand his ?state of mind at that moment@. (4uring !#7$ #7'
5n this picture the computerPs state of mind is the causal intermediary between observed symbols
and subse/uent action. ittgenstein is against this view.
=oes a calculating machine calculate0 Imagine that a calculating machine had come intoe<istence by accident> now someone accidentally presses its knobs (or an animal walks over it'and it calculates the product &%X&*… Imagine that calculating machines occurred in nature, butthat people could not pierce their cases. -nd now suppose that these people use these appliances,say as we use calculation, though of that they know nothing. 4hus, e.g., they make predictionswith the aid of calculating machines, but for them manipulating these /ueer objects ise<perimenting. 4hese people lack concepts which we have> but what takes their place0 4hink ofthe mechanism whose movement we saw as a geometrical (kinematic' proof$ clearly it would notnormally be said of someone turning the wheel that he was proving something. IsnPt it the same
with someone who makes and changes arrangements of signs as an e<perimentK> even whenwhat he produces could be seen as a proof0 (ittgenstein !%7$ E, D&'
4here are no causal connections in a calculation, only the connections of the pattern. -nd itmakes no difference to this that we work over the proof in order to accept it. 4hat we aretherefore tempted to say that it arose as the result of a psychological e<periment. For the psychical course of events is not psychologically investigated when we calculate……Qou arenPtcalculating if, when you get now this, now that result, and cannot find a mistake, you accept thisand say$ this simply shows that certain circumstances which are still unknown have an influenceon the result. 4his might be e<pressed$ if calculation reveals a causal connection to you, then youare not calculating… hat I am saying comes to this, that mathematics is normative(ittgenstein !%7 !2"Y$ EII, D"'.
5n this view calculation and computing are mathematical activities. ittgenstein also claims thatwhat we do when we run programs on physical machines is an e<perimental activity. But is thisright0 -re we e<perimenting when we run programs on physical machines or are we using themto perform physical calculations0
4here is also an apparent conflict between the insistence that atomic instructions are meaninglessand the principle of compositionality for semantic theories (see the entry on compositionality'. Inits modern form, the supporting argument for compositionality can be found in Frege.
… the possibility of our understanding sentences which we have never heard before rests
evidently on this, that we can construct the sense of a sentence out of parts that correspond towords. (Frege !30'
+ompetent speakers can understand a comple< e<pression that they never encountered before.-nd, so the argument goes, the only plausible way they can do this is by the employment of their knowledge of the structure of the e<pression together with knowledge of the individual meaningsof its simple constituents. 4his is an inference to the best e<planation. In the case of programming languages, without some account of the meanings of atomic constructs of thelanguage, and how the meanings of the constructors are fi<ed, it is hard to see how one couldunderstand and produce the programs of a programming language. Lnfortunately, under theassumption that all basic instructions are meaningless, it is hard to maintain any compositional
theory of meaning$ if all basic instructions are meaningless, the compositionality thesis wouldlead us to conclude that all programs in the language are meaningless.
6.4 The Physical Church8Turin% Thesis
8any take it for granted that the +hurch94uring thesis characteriCes and prescribes actual physical computation. Some claim (see the entry on the +hurch94uring thesis by +opeland(&**"'' that the thesis as proposed by +hurch and 4uring only concerns the interpretation ofmathematical computations. -ndrew 6odges (&*' disagrees. 6e argues that +hurch and 4uringdid not distinguish between the two interpretations. 4his is the historical dispute. But theimportant one concerns the capabilities of actual machines$ does the physical thesis (8' hold
good0 In the following, taken from +opeland (&**"', the phrase calculated by a machine refersto a machine that conforms to the laws of physics.
4hesis 8$hatever can be calculated by a machine (working on finite data in accordancewith a finite program of instructions' is 4uring9machine9computable.
Nandy proposed four principles that are intended to characteriCe computation by a physicalmachine. 6e shows that such machines e<actly agree with 4uringPs characteriCation (NandyPs4heorem'. +opeland and Shagrir (&**2, &*' suggest that NandyPs characteriCation of a discretedeterministic mechanical device is too narrow, and conse/uently there are e<amples of possible
physical machines whose capabilities go beyond the class of 4uring computable functions. 8anyof these re/uire infinite speedup, whereby an infinite number of computations can be physicallycarried out in a finite time. Zuantum computing has been cited as a possible e<ample for suchmachines, but this has been disputed (6agar &**2'. 5n page 2 in a footnote, =ummett (&**7'contains the view that the very notion of performing an infinite number of physical operations ina finite time is just confused.
5ne /uestion that seems /uite puCCling is this$ imagine we have constructed a physical machinethat is claimed can decide the halting problem0 6ow would one verify its correctness0 - plausible way is to construct a semi9decidable machine for the halting problem. e could thencheck that the halting machine is in agreement on the programs that terminate. But on those thatdonPt, how would we determine if it produced the right results0 For further discussion see
+opeland and Shagrir (&**2'.
19. )ther Topics
8any of the topics we have not covered have e<isting or forthcoming entries. +omputational+omple<ity theory is covered in computability and comple<ity. and will be the subject of aforthcoming article devoted to it by alter =ean. nformation in its various guises is alsocovered in two entries$ semantic conceptions of information and information. +omputer ethics iscovered in computer and information Mthics. 4he logical aspects of artificial intelligence arecovered in logic and artificial intelligence. 4here is also a general entry on emergent properties.
7iblio%raphy
• -bramsky, S. and N. 8c+usker, !!%, ?Names and Full -bstraction for the :aCy:ambda9+alculus,@ In =. 1oCen (ed.' !enth "nnual #ymposium on $ogic in %omputer
#cience, IMMM +omputer Society Aress. pp. J3#.
• -bramsky, S., A. 8alacaria, and G. Ragadeesan, !!3, ?Full -bstraction for A+F,@ In 8.6agiya and R. +. 8itchell (eds', !heoretical "spects of %omputer #oftware& nternational #ymposium !"%# '()* #endai* +apan* "pril ,(-..* ,((), Springer9Eerlag, J%.
• -lama, R., &*#, ?4he :ambda +alculus@, !he #tanford Encyclopedia of Philosophy (Fall&*# Mdition', Mdward H. [alta (ed.', forthcoming LG: )\http$plato.stanford.eduarchivesfall&*#entrieslambda9calculus].
• -llen, G. R., !!2, " Formal "pproach to #oftware "rchitecture, Ah.=. 4hesis, +omputerScience, +arnegie 8ellon Lniversity. Issued as +8L 4echnical Geport +8L9+S9!2933. -llen !!2 available on line
• -ngius, H., &*#, ?-bstraction and IdealiCation in the Formal Eerification of Software,@ 1inds and 1achines. &#(&'$ &J&&7.
• -rkoudas, 1. and S. Bringsjord, & **2, ?+omputers, Rustification, and 8athematical1nowledge,@ 1inds and 1achines, 2(&'$ "%J&*&.
• -shenhurst, G. :. (ed.', !"!, ?:etters in the -+8 Forum@ %ommunications of the "%1 ,#&(#'$ &"2. -shenhurst !"! available onlineK
• =e 8illo, G. :., G. R. :ipton, and -. R. Aerlis, !2!, ?Social Arocesses and Aroofs of4heorems and programs,@ %ommunications of the "%1 , &&(%'$ &2J&".
• =evlin, 1., !!3, 1athematics& !he #cience of Patterns& !he #earch for 6rder in $ife*
• 6ankin, +., &**3, "n ntroduction to $ambda %alculi for %omputer #cientists, :ondon$1ingPs +ollege Aublications.
• 6arrison, R., &**", ?Formal Aroof4heory and Aractice,@ 3otices of the "merican
1athematical #ociety, %%('$ #!%J3*7.
• 6enson, 8. +., !"2, Elements of Functional Programming , 5<ford$ Blackwell.
• 6oare, +. -. G., !7!, ?-n -<iomatic Basis for +omputer Arogramming,@%ommunications of the "%1 , &(*'$ %27J%"*.
• JJJ, !2#, ?Hotes on =ata Structuring,@ in 5.9R. =ahl, M.. =ijkstra, and +.-.G. 6oare(eds.', #tructured Programming , :ondon$ -cademic Aress, pp. "#J23.
• JJJ, !", ?4he MmperorPs 5ld +lothes,@ %ommunications of the "%1 , &3(&'$ 2%J"#.
• 1ripke, S., !"&, 5ittgenstein on Rules and Pri2ate $anguage, +ambridge, 8-$ 6arvardLniversity Aress.
• 1roes, A., &**, ?Mngineering and the =ual Hature of 4echnical -rtefacts,@ %ambridge
+ournal of Economics, #3('$ %J7&.
• JJJ, &*&, !echnical "rtefacts& %reations of 1ind and 1atter& " Philosophy of
Engineering 8esign, =ordrecht$ Springer.
• 1roes, A. and -. 8eijers, &**7, ?4he dual nature of technical artefacts,@ #tudies in
<istory and Philosophy of #cience, #2$ J3.
• :andin, A. R., !73, ?4he mechanical evaluation of e<pressions,@ !he %omputer +ournal ,7(3'$ #*"J#&*.
• :oewenheim, L., !"!, ?:egal Arotection for +omputer Arograms in est Nermany,@ /erkeley !echnology $aw +ournal , 3(&'. :oewenheim !"! available onlineK
• :uckham, =. +., !!", ?Gapide$ - :anguage and 4oolset for +ausal Mvent 8odeling of=istributed System -rchitectures,@ in Q. 8asunaga, 4. 1atayama, and 8. 4sukamoto(eds.', 5orldwide %omputing and its "pplications* 55%"'(=, Berlin$ Springer, pp. ""J !7. :uckham !!" available onlineK
• 8agee, R., H. =ulay, S. Misenbach, and R. 1ramer, !!%, ?Specifying =istributedSoftware -rchitectures,@ Proceedings of >th European #oftware Engineering %onference
?E#E% (>@, Berlin$ Springer9Eerlag, pp. #2J%#.
• 8artin9:;f, A., !"&, ?+onstructive 8athematics and +omputer Arogramming,@ in $ogic*
1ethodology and Philosophy of #cience (Eolume EI$ !2!', -msterdam$ Horth96olland, pp. %#J2%.
• 8eijers, -. . 8., &**, ?4he relational ontology of technical artifacts,@ in A. -. 1roesand -. . 8. 8eijers (eds', !he Empirical !urn in the Philosophy of !echnology,-msterdam$ Mlsevier.
• 8itchelmore, 8. and A. hite, &**3, ?-bstraction in 8athematics and 8athematics:earning,@ in 8.R. 6_ines and -.B. Fuglestad (eds.', Proceedings of the .=th %onferenceof the nternational Group for the Psychology of 1athematics Education (Eolume #',
• 8oor, R. 6., !2", ?4hree 8yths of +omputer Science,@ !he /ritish +ournal for the
Philosophy of #cience, &!(#'$ &#J&&&.
• 8organ, +., !!3, Programming From #pecifications, Mnglewood +liffs$ Arentice 6all.8organ !!3 available onlineK
• Aears, =., &**7, Paradox and Platitude in 5ittgenstein's Philosophy, 5<ford$ 5<fordLniversity Aress.
• Aiccinini, N., &**", ?+omputation without Gepresentation,@ Philosophical #tudies,#2(&'$ &*7J&3. Aiccinini &**" available online (this version lists &**7 as publication
date but that seems to be the online publication date'K
• Gapaport, . R., !!!, ?Implementation Is Semantic Interpretation,@ !he 1onist , "&('$*!J#*. Gapaport !!! available online (pdf'K
• JJJ, &**%, ?Implementation as Semantic Interpretation$ Further 4houghts,@ +ournal of
• Gosenberg, -., &*&, !he Philosophy of #cience, :ondon$ Goutledge.
• Searle, R. G., !!%, !he %onstruction of #ocial Reality, :ondon$ Aenguin.
• Shanker, S. N., !"2, ?ittgenstein versus 4uring on the nature of +hurchPs thesis,@ 3otre 8ame +ournal of Formal $ogic, &"(3'$ 7%J73!. Shanker !"2 available onlineK
• Shapiro, S. !"#, ?8athematics and Geality,@ Philosophy of #cience, %*(3'$ %&#J%3".
• 4echnical +orrespondence, !"!, "%1 8igital $ibrary, %ommunications of the "%1 #&(#'$ #23J". :etters from Rames +. Aleasant, :awrence Aaulson-vra +ohen8ichaelNordon, illiam Bevier8ichael Smithilliam Qoung, 4homas +lune, StephenSavitCky, Rames FetCer. Getrieved from 4echnical correspondence$http$dl.acm.orgcitation.cfm0doid)7&*7%.#%!&2
• 4homasson, -., &**2, ?-rtifacts and human concepts,@ in S. :aurence and M. 8argolis,%reations of the 1ind& Essays on "rtifacts and !heir Representations, 5<ford$ 5<fordLniversity Aress.
• 4uring, -. 8., !#7, ?5n +omputable Humbers, with an -pplication to the Entscheidungsproblem,@ Proceedings of the $ondon 1athematical #ociety (Series &', 3&$&#*J7%.
• 4urner, G. &**2, ?Lnderstanding Arogramming :anguages,@ 1inds and 1achines, 2(&'$&*#J&7.
• JJJ, &**!b, ?4he 8eaning of Arogramming :anguages,@ "P" 3ewsletters, !('$ &J2.4urner &**!b available online (pdf'K
• JJJ, &**, ?Arogramming :anguages as 8athematical 4heories,@ in R. Eallverd` (ed.',!hinking 1achines and the Philosophy of %omputer #cience& %oncepts and Principles,
6ershey, A-$ INI Nlobal, pp. 77J"&.
• JJJ, &*, ?Specification,@ 1inds and 1achines, &(&'$ #%J%&.
• JJJ, &*&, ?8achines,@ in 6. [enil (ed.', " %omputable 7ni2erse& 7nderstanding and
Exploring 3ature as %omputation, :ondon$ orld Scientific Aublishing+ompanyImperial +ollege Aress, pp. 7#J27.
• JJJ, &*#, ?Arogramming :anguages as 4echnical -rtefacts,@ Philosophy and
!echnology, =5I$ I *.**2s##329*&9**!"9C.
• 4ymocCko, 4., !2!, ?4he Four +olor Aroblem and Its Ahilosophical Significance,@ !he
+ournal of Philosophy, 27(&'$ %2J"#.
• JJJ, !"*, ?+omputers, Aroofs and 8athematicians$ - Ahilosophical Investigation of theFour9+olor Aroof,@ 1athematics 1aga:ine, %#(#'$ #J#".
• Eermaas, A. M. and . 6oukes, &**#, ?-scribing functions to technical artifacts$ -challenge to etiological accounts of function,@ /ritish +ournal of the Philosophy of#cience, %3$ &7J&"!. Eermaas and 6oukes &**# available onlineK
• ang, 6., !23, From 1athematics to Philosophy, :ondon$ Goutledge, 1egan O Aaul.
• hite, N., &**#, ?4he Ahilosophy of +omputer :anguages,@ in :. Floridi (ed.', !he
/lackwell Guide to the Philosophy of %omputing and nformation, 8alden$ iley9Blackwell, pp. #"J#&7.
• ittgenstein, :., !%# &**K, Philosophical n2estigations, translated by N. M. 8.-nscombe, #rd Mdition, 5<ford$ Blackwell Aublishing.
• JJJ, !%7 !2"K, Remarks of the Foundations of 1athematics, N.6. von right, G.Ghees, and N.M.8. -nscombe (eds.'> translated by N.M.8. -nscombe, revised edition,5<ford$ Basil Blackwell.
• oodcock, R. and R. =avies, !!7, 7sing C& #pecification* Refinement* and Proof ,
Mnglewood +liffs$ Arentice 6all.
• right, +. !"#, Frege's %onception of 3umbers as 6b9ects, -berdeen$ -berdeenLniversity Aress.
Academic Tools
6ow to cite this entry.Areview the A=F version of this entry at the Friends of the SMA Society.:ook up this entry topic at the Indiana Ahilosophy 5ntology Aroject (InAh5'.
Mnhanced bibliography for this entry at AhilAapers, with links to its database.
)ther nternet -esources
• -+8 (ed.', &*#, -+8 4uring -ward :ectures.
• =uncan, ., &**!, ?8aking 5ntological Sense of 6ardware and Software@. Lnpublishedmanuscript. Lniversity of Buffalo.
• Nroklaw, &*, ?Software is 8athematics4he Heed for =ue =iligence@, by AoIG.
• Nroklaw, &*&, ?hat =oes ?Software is 8athematics@ 8ean0@ Aart and Aart &, byAoIG.
• 6uss, M., !!2, !he % $ibrary Reference Guide, eb 8onkeys, Lniversity of Illinois atLrbana9+hampaign.
• Gapaport, . R. (ed.', &**, ?+an Arograms be +opyrighted or Aatented0@. eb site (lastupdated & 8arch &**', Ahilosophy of +omputer Science, Lniversity at Buffalo, StateLniversity of Hew Qork.
• Smith, B., &*&, ?:ogic and Formal 5ntology@. - revised version of the paper whichappeared in R. H. 8ohanty and . 8c1enna (eds', !"!, <usserl's Phenomenology& "
!extbook , :anham$ Lniversity Aress of -merica.
• 4urner, Gay and -mon Mden, &*, ?4he Ahilosophy of +omputer Science@, #tanford
Encyclopedia of Philosophy (inter &* Mdition', Mdward H. [alta (ed.', LG: )\http$plato.stanford.eduarchiveswin&*entriescomputer9science]. 4his was the
previous entry on the philosophy of computer science in the #tanford Encyclopedia of
Philosophy see the version history.K
• Ahilosophy of +omputer Science at Buffalo
• +enter for Ahilosophy of +omputer Science
-elated /ntries
artificial intelligence$ logic and computability and comple<ity computational comple<itytheory computer and information ethics function$ recursive information information$semantic conceptions of mathematics, philosophy of technology, philosophy of
Ac:no#led%ments
4his is a completely rewritten and updated version of the entry on the philosophy of computerscience, written by one of the authors of the previous version. See the reference to 4urner andMden &* in the 5ther Internet Gesources for the link to the previous, coauthored version.
