1. COMPUTATIONAL ARTEFACTS The Technical Artefacts of Computer Science

2. Computational Artefacts Functional Programs Embedded Systems Robots Compilers Interpreters Databases Computer Games Search Engines Web Pages Visual Processors Natural language systems Type inference systems Evolutionary programs …..

3. A Core Activity of Computer Science The Specification, Design and Construction of Computational Artefacts

4. Philosophy of Computer Science Any philosophy of computer science should involve reflection on this activity. In our case the result is a fusion or amalgam of o Philosophy of mathematics o Philosophy of technology With bit parts played by epistemology, the philosophies of mind, language and science.

5. Outline 1.Technical ArtefactsTechnical Artefacts 2.The Languages of Computer ScienceThe Languages of Computer Science 3.Formal SemanticsFormal Semantics 4.Axiomatic TheoriesAxiomatic Theories 5.DefinitionDefinition 6.ImplementationImplementation 7.CorrectnessCorrectness 8.AgencyAgency 9.ComplexityComplexity

6. TECHNICAL ARTEFACTS

7. The Dual Nature of Technical Artefacts Technical artifacts are, at least prima facie, always physical objects, but they are also objects that have a certain function. Looked upon merely as physical objects, they fit into the physical or material conception of the world. Looked upon as functional objects, however, they do not. The concept of function never appears in physical descriptions of the world; it rather belongs to the intentional conceptualization. This is shown, for one thing, by the fact that attributions of function lend themselves to normative judgments - artifacts can perform their function well or badly - and normative statements make sense only within the intentional conceptualization. Technical artifacts thus have a dual nature: they cannot exhaustively be described within the physical conceptualization, since this has no place for their functional features, nor can they be described exhaustively within the intentional conceptualization, since their functionality must be realized in a physical structure that is adequate to it. Peter Kroes and Anthonie Meijers

8. Function and Structure Technical artefacts are fixed by two sets of properties: o Functional properties o Structural properties Functional properties concern the artefacts purpose: a clock is for telling the time and a kettle is for heating water. Structural properties pertain to an artefact’s physical makeup. They provide the causal mechanisms that enable an artefact to meet its functional requirements. Both characterisations seem necessary for something to count as a technical artefact. Without one it won’t work and without the other we don’t know what counts as working.

9. Programs as Technical Artefacts Programs may be seen as technical artefacts in several ways depending on what we take to be the artefact and what we take to be the function. Function = Symbolic Program Structure = Fixed by Physical Implementation Artefact = Physical Program Function = Abstract Specification Structure = Fixed by the programming language Artefact = Symbolic Program

10. THE LANGUAGES OF COMPUTER SCIENCE

11. Computational Functions Are expressed in specially designed languages. There are hundreds of them. They include architectural description, specification, programming, web ontology, relational query, and hardware description languages etc… Generally, these are formal languages with a precise syntax.

12. Architectural Description Languages At a high level of abstraction are architectural description languages. These are employed to specify the large-scale structure of computational systems. Example: e.g. Rapide, Darwin, Wright, Acme. Garland provides an analysis of the shared concepts of these languages. In the analysis, the common types of objects used for representation are Components, Connectors and Systems. Components generally include the primary computational elements and data stores of a system. Typical examples include clients, servers, objects, blackboards, and databases. Connectors represent interactions among components; they are the glue of architectural design. Examples include simple forms of interaction, such as pipes, procedure calls, and event broadcasts.

13. Syntax

14. Specification Languages At a lower level of abstraction are the languages that are explicitly termed specification languages (e.g., VDM (Jones, 1990), Z (Woodcock, 1996), B (Abrial, 1996)). For example, in Z the central vehicle of expression is the notion of schema.

15. Syntax

16. Programming Languages The workhorse Languages of the discipline. A large number of them: Python, Haskell, Java, Pascal,.. Procedural, functional, logic, object oriented Etc.

17. Simple Procedural Language

18. The  calculus of Milnor is a language of processes and concurrency. It is the core of the Occam programming language. Some of its syntax might be expressed by the following rules. Occam

19. Hardware Description Languages These describe the behaviour of individual physical components. A digital system in VHDL consists of a design entity that may contain other component entities. Each entity consists of a declaration part and an architecture body. The former defines the input and output signals and the latter contains the description of the entity and is composed of interconnected entities, processes and components, all operating concurrently.

20. Hardware Description Languages D: Declaration B: Architecture Body : Entity

21. SQL Relational Query language Basic SQL Query Format t: Attribute T:Type P: Predicate Select t From T Where P: Query

22. Formal Languages Precise syntax. Must support parsing and type checking. Type structure encodes level of abstraction and the means of representation Artificial Languages: semantic interpretation required.

23. FORMAL SEMANTICS

24. Arguments For Formal Semantics 1.The Argument From Ambiguity 2.The Argument From Design 3.The Argument From Consistency 4.The Argument From Correctness

25. Ambiguity Any discussion on the foundations of computing runs into severe problems right at the start. The difficulty is that although we all use words such as ‘name’, ‘value’, ‘program’, ‘expression’ or ‘command’ which we think we understand, it often turns out on closer investigation that in point of fact we all mean different things by these words, so that communication is at best precarious. These misunderstandings arise in at least two ways. The first is straightforwardly incorrect or muddled thinking. An investigation of the meanings of these basic terms is undoubtedly an exercise in mathematical logic and neither to the taste nor within the field of competence of many people who work on programming languages. As a result the practice and development of programming languages has outrun our ability to fit them into a secure mathematical framework so that they have to be described in ad hoc ways. Because these start from various points they often use conflicting and sometimes also inconsistent interpretations of the same basic terms. (Strachey C.).

26. Ambiguity But to me, each revision of the document simply showed how far the initial Flevel implementation had progressed. Those parts of the language that were not yet implemented were still described in free-flowing flowery prose giving promise of unalloyed delight. In the parts that had been implemented, the flowers had withered; they were choked by an undergrowth of explanatory footnotes, placing arbitrary and unpleasant restrictions on the use of each feature and loading upon a programmer the responsibility for controlling the complex and unexpected side-effects and interaction effects with all the other features of the language. ― C.A.R. HoareC.A.R. Hoare

27. Definitional Words such as ‘name’, ‘value’, ‘program’, ‘expression’ or ‘command’ are not natural language terms. They are technical terms whose meaning is not precisely fixed by informal practice. Semantics is definitional: it tells us what these notions are to mean.

28. Design In particular, Java has integrated multithreading to a far greater extent than most programming languages. It is also one of the only languages that specifies and requires safety guarantees for improperly synchronized programs. It turns out that understanding these issues is far more subtle and difficult than was previously thought. The existing specification makes guarantees that prohibit standard and proposed compiler optimizations; it also omits guarantees that are necessary for safe execution of much existing code (Pugh, 2000)

29. Design Programming languages on the whole are very much more complicated than they used to be: object orientation, inheritance, and other features are still not really being thought through from the point of view of a coherent and scientifically well-based discipline or a theory of correctness. My original postulate, which I have been pursuing as a scientist all my life, is that one uses the criteria of correctness as a means of converging on a decent programming language design—one which doesn’t set traps for its users, and ones in which the different components of the program correspond clearly to different components of its specification, so you can reason compositionally about it. [...] The tools, including the compiler, have to be based on some theory of what it means to write a correct program. – Oral history interview by Philip L. Frana, 17 July 2002, Cambridge, England; Charles Babbage Institute, University of Minnesota.[ http://www.cbi.umn.edu/oh/display.phtml?id=343]http://www.cbi.umn.edu/oh/display.phtml?id=343

30. Design Notions such as threading and synchronization are complex concepts for which we require: A better conceptual understanding. A more exact formulation. Ability to predict complex properties.

31. Consistency My point is that formalism without eventual interpretation is in the end useless. Now it may turn out that a system such as the lambda calculus will have an interpretation along standard lines but… A type-theoretical alternative to ISWIM, CUCH, OWHY 31

32. Correctness To support the kind of reasoning necessary for the design and construction of complex computational artefacts requires that we reason about abstractions. For example, any programmer will need to argue that his program meets its specification. Such arguments are not optional; at some level, and with some degree of precision, one cannot construct a program or system without undertaking some abstract reasoning.

33. Abstract Device When a physicist does an experiment, two very distinct representations of the instrument on which he is working fill his mind: one is the image of the concrete instrument that he manipulates in reality; the other is a schematic model of the same instrument, constructed with the aid of symbols supplied by theories; and it is on this ideal and symbolic instrument that he does his reasoning, and it is to it that he applies the laws and formulas of physics. A manometer, for example, is on the one hand, a series of glass tubes, solidly connected to one another filled with a very heavy metallic liquid called mercury and on the other by the perfect fluid in mechanics, and having at each point a certain density and temperature defined by a certain equation of compressibility and expansion (Duhem, 1954).

34. Normative Semantics must provide a normative guide to the compiler write and the user. It must provide an implementer with a notion of correctness for any proposed implementation. It must inform the user about the correct use of constructs. It must support the reasoning that demonstrates correctness.

35. Mathematical Techniques Denotational. Operational. Hoare Style. …

36. Denotational The language is given a semantic interpretation in the mathematical theory. Set theory Type theory Category theory Game Theory

37. Form of Denotational Semantics S[F, A, M] F is interpreted in medium M (e.g. Set theory, etc.) – the image of F being A.

38. Operational Where applicable e.g. (PL) given by rules of evaluation. E.g.  Given by formal rules that govern the constructs of the language. Still mathematical in nature. Can be put in form S[F, A, M].

39. AXIOMATIC THEORIES

40. Axiomatic Theories Rules that directly govern reasoning about the constructs of the language. Directly supports reasoning about correctness. The concepts, relations and rules of the system define the mathematical structure.

41. Hilbert... a concept can be fixed logically only by its relations to other concepts. These relations, formulated in certain statements I call axioms, thus arriving at the view that axioms... are the definitions of the concepts.

42. Axiomatic Theories From this perspective each language is an axiomatic theory of its constructs. Theories of types, operations, processes, design patterns,… Applies at all levels of abstraction.

43. Rules For ADLS At the level of architectural design, we shall need to reason about components and connectors. For this we shall need some account of their properties e.g. connecting devices be associative.

44. Specifications At the level of individual specifications, one of the central mathematical devices is the notion of a schema. In the specification language Z (Spivey, 1998) a simple specification has the form This introduces a new relation whose interpretation is fixed by the schema on the right. More explicitly, it is governed by the following rule: for an object of type T, the relation and the predicate of the schema coincide.

45. Programming Languages A central semantic technique for these languages employs an operational definition. In its modern guise it uses a mechanism of evaluation where, in its simplest form, the evaluation relation for imperative languages takes the following shape. This indicates that evaluating P in state s terminates in state s'. For example, the rules for a simple while loop would take the following form.

46.  Calculus For the  calculus the following rules govern the parallel operator where is process equivalence.

47. Axiomatic Theories On this approach, the languages of computer science are axiomatic theories of programs, processes, finite sets and functions,.... Directly supports correctness arguments.

48. DEFINITION

49. Functional Specifications Taken at face value, functions in computer science are (stipulative) definitions. This applies to architectural descriptions, specifications, programs and hardware descriptions. They carve out new objects (programs, processes, finite sets and functions...) in their underlying ontologies.

50. Z Specifications: new typed relations Bank Deposit:Customer ℕ ∀ xDeposit(x)<Min Withdraw n: ℕ, c:Customer ΔBank Deposit′(c)=Deposit(c)-n

51. Programs i=0; fact=1; While i<=n do i:=i+1; fact:=fact*i Via its semantics this defines an operation on the underlying state of the abstract machine.

52. Process The following is a definition of the handover protocol for the GSM Public Land Mobile Network expressed in the ∏-calculus. Car(talk, switch) = talk.car(talk,switch) | switch(talk’,switch’).car(talk’,switch’)

53. Central Activity of Computer Science This definitional activity is present in architectural design, specification, programming and hardware description, etc. It is one of the characterising intellectual activities of the whole discipline. But it is only half the picture.

54. IMPLEMENTATION

55. From Definition to Specification The definitional activity provides the function of computational artefacts. But a definition may just form part of a mathematical exploration. A definition acts as a specification when it is given jurisdiction over the properties of a device or system – to be constructed or actual. The function has normative jurisdiction over the process of implementation, or once constructed, the artefact itself.

56. Example Fac(0)=1 Fac(n+1)=(n+1)*Fac(n) May be used as the specification of the While program for factorial. i=0; fact=1; While i<=n do i:=i+1; fact:=fact*i The definition acting as a specification determines whether or not this program is correct. Here, the structural description/the medium of implementation might be our While programming language.

57. Medium of Implementation The structural properties tell us what the medium of implementation is. In this case which programming Language to employ. So the actual relationship is between  Definition  Medium of Implementation  Artefact

58. Example Definition = Factorial function Medium of Implementation = While programming language Artefact = A While program

59. Example Definition = UML specification Medium of Implementation = Java programming language Artefact = Java Program The structural description fixes the medium of implementation, in this case the Java programming language.

60. Implementation and Specification A is an Implementation in medium M of the definition F or equivalently Definition F is a Specification for Artefact A to be constructed in medium M We shall write this as a relation schema I[F, A, M].

61. Kinds of Computational Artefacts The literature takes technical artefacts to be physical things. Technical artefacts are, at least prima facie, always physical objects. Peter Kroes and Anthonie Meijers However, prima facie, Computer science produces both physical and abstract ones.

62. UML and Java Definition: UML specification of a Java program. Medium of Implementation: Java Artefact: Java program. The artefact, at least from the programmer’s perspective, is not a physical thing. It is the abstract Java program. This is determined not by any physical realization but by its linguistic form together with its semantic interpretation on an underlying abstract machine. The programmer constructs the program from the medium of the Java programming language. She may have little awareness or knowledge of any physical thing that will eventually run on some physical device or computer.

63. Z and Python Definition = Z Specification Medium of Implementation = Python programming language Artefact = Python program

64. Mathematical Artefacts Prima facie these are abstract artefacts subject to formal rules. On the face of it they are mathematical objects. Whatever we take the latter to be.

65. Semantics as Implementation (Fetzer, 1988) observes that programs have a different semantic significance to theorems. In particular, he asserts: …programs are supposed to possess a semantic significance that theorems seem to lack. For 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. (Fetzer, 1988) This seems to say that the physical properties of the implementation contribute to the meaning of programs written in the language. In a similar vein (Colburn T. R., 2000) insists that the simple assignment statement A := 13×74 is semantically ambiguous between something like the abstract operational semantics, and the physical one given as: physical memory location A receives the value of physically computing 13 times 74. (Colburn 2000)

66. Causal Theory of Function Where the semantics of the language provides the function and the physical implementation the artefact, the implementation interpretation is a special case of the Causal Theory of Function. No material object, no physical capacity, no technical function (Cummins, 1975). In other words, the function must reside in the physical thing - since without it there would be no function.

67. No Criterion of Correctness However, if an actual physical machine is taken 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. Multiplication does not mean multiplication but rather what the physical machine actually does when it simulates multiplication. In this case the causal theory of function becomes the dispositional theory of meaning. This is the general problem with the function as artefact approach: there is no independent notion of correctnss.

68. Kripke on Machines and Meaning Actual machines can malfunction: through melting wires or slipping gears they may give the wrong answer. How is it determined when a malfunction occurs? By reference to the program of the machine, as intended by its designer, not simply by reference to the machine itself. Depending on the intent of the designer, any particular phenomenon may or may not count as a machine malfunction. A programmer with suitable intentions might even have intended to make use of the fact that wires melt or gears slip, so that a machine that is malfunctioning for me is behaving perfectly for him. Whether a machine ever malfunctions and, if so, when, is not a property of the machine itself as a physical object but is well defined only in terms of its program, stipulated by its designer. Given the program, once again, the physical object is superfluous for the purpose of determining what function is meant. 68

69. Implementation as Semantic Interpretation There is something more general going on here that has little to do with the fact that the medium of implementation is physical. Implementation as Semantic Interpretation. This is the theory of implementation of Rapaport, W. J. (1999).

70. Semantic Interpretation Suppose that F is propositional logic and M is set theory. The translation of F into M yields a semantic interpretation of F as sets. On this account M provides the meaning of the propositional connectives. S(A  B) = S(A)  S(B) S(A  B) = S(A)  S(B)

71. Soundness Here the semantic interpretation has normative priority and it is the rules of propositional logic under scrutiny. The rules of the logic (e.g. Modus Ponens) need to be proven sound relative to this semantic interpretation. It is the rules that are correct or not relative to the semantic interpretation.

72. Implementation But we may also interpret matters as implementation i.e. I(A  B)=I(A)  I(B) I(A  B)=I(A)  I(B) Here the logical connectives are implemented as set operations.

73. Correctness We are no longer seeking soundness but the correctness of the implementation. The medium of implementation is set theory and the artefact is the set theoretic operations that form the interpretation. The logical rules have normative priority. It is the artefact that is correct or not. If any of the logical rules are not sound we need to change the implementation. If we implement implication as union, it is not correct.

74. Fundamental Difference There is a fundamental difference between semantic interpretation and implementation This has do do with what has normative governance over what. Where there is disagreement in the semantic case we blame the logical rules since the semantic interpretation has priority. In the implementation case we blame the set theoretic implementation since the logical rules have priority.

75. CORRECTNESS

76. Different Notions Different notions of correctness at different levels of abstraction. Type checking. Program Correctness. All abstract levels are mathematical in Nature. But we also have: correctness of physical devices.

77. UML and Java Consider the standard UML specification of the observer pattern. Each of the components has to be implemented. In particular, there has to be a Java class for subject. package com.journaldev.design.observer; public interface Subject {public void register(Observer obj); public void unregister(Observer obj); public void notifyObservers(); public Object getUpdate(Observer obj) } In the Java class description only the type of the individual methods is fixed by a UML specification. At this level of abstraction the correctness of the Java classes relative to the UML specification amounts to little more than an agreement of methods names and and their types.

78. Specification and Program Consider the following specification of a square root function written in the style of the specification language VDM (Jones, 1990). SQRTP (x:Real, y:Real) Pre : x ≧ 0 Post: y  y=x and y ≧ 0 Mathematically, the specification defines an abstract relation, SQRTP (x, y), that is determined as follows. ∀ x:Real. ∀ y:Real. x ≧ 0  (SQRTP (x, y)  y ∗ y=x and y ≧ 0) where Real is a data type of real numbers.

79. Correctness What does it mean for a Pascal program P to satisfy it? More specifically, what does the following amount to? I[SQRTP, P, Pascal] Presumably, via the semantics of Pascal, P carves out a relationship R P between its input and output, its extension. The minimal correctness condition insists that this input/output relation satisfies the specification i.e. ∀ x:Real. ∀ y:Real ⋅ x ≧ 0→ (R P (x, y)  SQRTP (x, y))

80. Physical Correctness Consider a square root program S and a physical device that is intended to compute the square root of some class of numbers. Presumably correctness is given by the following condition. ∀ x:Real. ∀ y:Real ⋅ x ≧ 0→ (Squarerootdevice(x, y)  R S (x, y)) Of course Squarerootdevice is a physical relation and we must verify it in an empirical fashion. And here there is controversy.

81. Correctness Debate The notion of program verification appears to trade upon an equivocation. Algorithms, as logical structures, are appropriate subjects for deductive verification. Programs, as causal models of those structures, are not. The success of program verification as a generally applicable and completely reliable method for guaranteeing program performance is not even a theoretical possibility. (Fetzer 1988: 1)

82. Ambiguity Much of the heat of this debate can be taken out by observing that opposite sides in the debate are employing different technical artefacts. Definition = Formal Specification Medium = Programming Language Artefact = Abstract Program Definition = Abstract Program Medium = Physical device Artefact = Physical Program

83. Form of Correctness Despite this apparent difference, all forms of correctness maybe expressed in a general form (possibly many relationships) that has the following shape ∀ x:T. ∀ y:T. P(x)→ (R A (I(x), I(y))  F(x, y)) where R A is the artefact relation, F the functional one and I an interpretation mapping.

84. Extensional Agreement But this raises a problem that applies to the whole correctness issue. We only seem to require that the physical system is in extensional agreement with the abstract one.

85. Extensionality To simplify matters consider a simple case where there are only 4 numbers in its domain say 9, 16, 25, 49. The computation table for the square root program may be easily computed by hand, and takes the form of a table with only 4 states (9,3), (16,4), (25,5) and (49,7). So we could implement the abstract square root program as a physical table with pairs of suitably labelled stones, laid out on the ground.

86. Applies Generally So far this has only plagued the issue of what constitutes a physical computation. But it would seem apply to all instance of correctness, even the abstract cases. No amount of causal or semantic maneuvering works. While some notion of extensional agreement is a necessary aspect of correctness it appears not to be sufficient.

87. AGENCY

88. The Physical and the Intentional In philosophy it is a classical question how these two descriptions – the description by means of the natural scientific or physical conceptualization and the description by means of the intentional conceptualization – are related to one another. The most notorious case in which these two descriptions are simultaneously applicable is the case of man itself, hence the well known mind-body problem. Kroes et all.

89. Agents What appears to be missing from the extensional account of correctness is some notion of agent or agent’s intention. One approach to function insists that it is agents who ascribe functions to artefacts. [t]he function of an artefact is derivative from the purpose of some agent in making or appropriating the object; it is conferred on the object by the desires and beliefs of an agent. No agent, no purpose, no function. (McLaughlin, 2001)

90. Function and Mental States Presumably, any artefact may have a function conferred on it by the desires or beliefs of an agent. For example, I may use a computer as a doorstop. Its function is then what I say it is. On one view the function is located in the mental states of the agent. But..

91. Kroes If functions are seen primarily as patterns of mental states,.. and exist, so to speak, in the heads of the designers and users of artefacts only, then it becomes somewhat mysterious how a function relates to the physical substrate in a particular artefact. (Kroes P., 2010).

92. Kripke Given... 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 sceptical challenge is not really an epistemological one. It purports to show that nothing in my mental history of past behavior -- not even what an omniscient God would know -- could establish whether I meant plus or quus. But then it appears to follow that there was no fact about me that constituted my having meant plus rather than quus. (Kripke, 1982)

93. Acting Intentionally On his commentary on Wittgenstein’s notion of acting intentionally David Pears suggests that anyone who acts intentionally must know two things: She must know what activity she is engaged in doing. She must know when she has succeeded.

94. Interpretation and Implementation Semantic interpretation and implementation may be in extensional agreement. However, they represent different intentional perspectives. When there is disagreement the semantic account and the implementation blame different things. Where there is disagreement in the semantic case we blame the logical rules since the semantic interpretation has priority. In the implementation case we blame the set theoretic implementation since the logical rules have priority.

95. Intentional Stance Establishing correctness is an externally observable rule based activity. It is a publically observable process. From the perspective of I[F, A, M], the relation between the function and artefact is manifest in the normative use of F. I must know that I am testing A for correctness and know that extensional agreement guarantees success. If I am asked why the implementation is right I, must be able to justify that it is with reference to F. When testing, if I am asked what I am doing, I will reply that I am trying to establish that my implementation is correct relative to F. It is the artefact that is blamed if there is no extensional agreement. It is the artefact that is subsequently revised.

96. COMPLEXITY

97. Complexity This rather clean view is tarnished by the complexity of computational artefacts. This applies not only to the artefacts themselves but to: Proofs of correctness. The Languages and their semantic accounts as mathematical theories.

98. Mathematical Proofs According to one account of the nature of mathematical proofs, one must be able to grasp them as a whole. While it may require study and reflection, genuine mathematical proofs must be such that they may be taken in all at once. Such proofs are referred to by (Hacking, 2014) as Cartesian proofs. For Descartes, reasoning is self-authenticating only if completely purified, completely stripped even of steps, so that you can grasp an entire proof as a whole. Mathematicians construct proofs, definitions and abstract concepts in tandem. Mathematics is a creative process involving all these aspects. In particular, the process of proving complex theorems may involve the invention of new mathematical concepts and notation. They may even await the invention of new areas of mathematics.

99. Grothndieck The mathematician (Grothndieck) see such proofs as the central ones of mathematics. He has a Cartesian vision: for him mathematical proofs should make all explicit and obvious. For him the important notion is not an individual proof but a proof idea. These are techniques of proof that rapidly generalise. Mathematical creation is a vision that little by little brings to light the obvious: great proofs are eventually clear and obvious, at least to the appropriate mathematical community, and, by logical standards, they may be quite informal.

100. Wittgenstein Wittgenstein also appears to favour such proofs when he asserts that proofs that are not graspable are not mathematical proofs (Wittgenstein 1956). Graspable, when applied to an axiom or whole proof amounts to being able to use it as a rule. Proofs must have a normative function. They are the means by which we measure correctness and malfunction. The ability to grasp their content is a preliminary to using them as rules. Presumably, if they cannot be taken in, they cannot be so used.

101. Correctness Proofs In contrast, program correctness proofs often involve long chains of shallow reasoning, usually carried out in a given formal system. Generally, correctness proofs have little conceptual significance; they do not bring about conceptual change and display connections between existing concepts. As a consequence, many would claim that correctness proofs are unlike proofs in ordinary mathematics e.g. (De Millo et al. 1979).

102. Programmers are always surrounded by complexity; we cannot avoid it. Our applications are complex because we are ambitious to use our computers in ever more sophisticated ways. Programming is complex because of the large number of conflicting objectives for each of our programming projects. If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather than part of its solution. ― C.A.R. HoareC.A.R. Hoare

103. Languages and Complexity The languages of computer science are often a complex mixture of notions and ideas that do not form any kind of tractable mathematical entity. A typical programming language has a large type structure including basic numerical types of various kinds and a collection of type constructors such as products and function spaces. Specification languages are almost equally complex in the structure with a variety of similar type constructors.

104. Languages as Mathematical Theories As axiomatic systems they contain a large number of axioms and rules. Indeed, many of the rules are hard to state precisely, and often come with cumbersome side conditions and provisos. They are not like group theory or topological spaces.

105. Not Mathematical One might then be tempted to claim that even its its specification/functional aspect, computer science is not really mathematical. This applies both to the underlying theories and the proofs of correctness.

106. Leibnitz on Proof (Hacking, 2014) reminds us that contemporary mathematics employs two notions of proof, which he refers to as the Leibnitzian and Cartesian. L-proofs are proofs in which every step is meticulously laid out, and can be checked, line by line, in a mechanical way. Such proofs are close to the kind of formal proofs found in formal logic. If these are to be taken as proofs, not only are correctness proofs mathematical proofs, but they are part of a new era of mathematical proofs.

107. Voevodsky Some claim that mathematics is becoming more L-like. Voevodsky (Voevodsky, 2010) believes that the most interesting and important proofs in current mathematics are L-like. He further claims that we are entering a new era which will be characterised by the widespread use of automated tools for proof construction and verification.

108. The Use of Provers and Checkers Theorem provers must themselves 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 program. We have the beginning of an infinite regress. One might only require that individual correctness proofs be checked by a computer rather than a human. But of course the proof-checker is itself in need of checking. Arkoudas and Bringsjord (2007) argue that since there is only one correctness proof that needs to be checked, namely that of the proof checker itself, then the possibility of mistakes is significantly reduced. But still we are left with an infinite regress. But is this different to short proofs?

109. Physical machines and Correctness But now we come to another issue: the role of physical machines in automatic proof construction. Such reliance renders the proofs of correctness dependent on physical devices: in the limit theorem proving systems run on physical machines, and so the software is only correct if these mechanical systems are. Ultimately, such correctness amounts to empirical verification. Consequently, some would argue that the correctness of software is an empirical enterprise not a mathematical one.

110. L - Theories Can we make the same distinction regarding mathematical theories? Cartesian theories are the usual ones: group theory, topological spaces. These are simple to express. L-style theories have many axioms and are hard to explore. They require the use of automatic tools. Programming Languages seem to be such theories.

111. How Mathematics Became Empirical Computer science is supplying tools for the checking of large proofs. But these physical systems can only be empirically tested. What has become of the traditional difference between mathematics and empirical science?