Abstract
The issue of proper functioning of operative computing and the utility of program verification, both in general and of specific methods, has been discussed a lot. In many of those discussions, attempts have been made to take mathematics as a model of knowledge and certitude achieving, and accordingly infer about the suitable ways to handle computing. I shortly review three approaches to the subject, and then take a stance by considering social factors which affect the epistemic status of both mathematics and computing. I use the analogy between mathematics and computing in reverse—that is to say, I consider operative computing as a form of making mathematics, and so attempt to learn from computing to mathematics in general. I conclude that “mathematics engineering” is a field to be both developed for practical improvement of doing mathematics and taken into consideration while philosophizing about mathematics as well.
Similar content being viewed by others
Notes
The term 'software engineering' was coined, apparently, around the middle of 1969, before the organization of the first conference of software engineering in October 1969 (See Pelaez 1988). As we are interested here in "engineering" of different aspects, not only of software, the term 'computing engineering' might be preferable, though mostly we use 'software engineering', for reasons of tradition.
Some crucial developments in (what is considered nowadays as) the theory of computer sciences, which has partly evolved prior to operational electronic computing, have been done as mathematical works in the full sense of the word. Here we consider latter developments of operational computing—particularly actual programming, design and creation of programming tools, running computer programs and operating computer systems.
Of course, this distinction is kind of similar to the well-known distinction in philosophy between the "a priori" and the "a posteriori" knowledge. (See also footnote 10 here.) In a later interview Fetzer said that such a distinction had been, indeed, in his mind, but he had chosen not to use these terms, considering them as too technical a philosophical terminology (see (MacKenzie 2001, p. 215)). Fetzer also distinguishes more delicately between statements which are learnt directly by observation and those which are deduced by induction and causality, but the important distinction here is the one described before.
For an updated list of publications, see, e.g., (Rapaport 2007) (up to 12 April 2007, and occasionally updated).
There are different kinds of "realistic" views in the philosophy of mathematics (as well as in philosophy in general). One view is taking mathematical objects to be existing independently of the human mind, so having their properties independently of our being in touch with those objects ("ontological realism"). Here we make do with a more moderate version of realism, assuming the truth value of mathematical statements is determined independently of the human mind ("truth-value realism") (see, e.g., (Shapiro 2000)). Of course, the first kind implies the second one.
An interesting discussion of such situations, from a philosophical point of view, appears on (Tymoczko 1979).
Here we use the well-known terms "analytic"/"synthetic", as our representation here fits that duo, at least in many of its common uses in philosophy, more than the aforementioned in footnote 4, "a priori"/"a posteriori". The relations between these two duos and the differences in meaning between them are a complicated and much-discussed philosophical issue, which we do not need to dwell on here. The terms are used mainly as "keyword connectors" to the relevant philosophical discussions.
Every programmer knows the process of debugged interpreting—a controlled executing in steps of a computer program, inspecting and checking the result of every step, comparing it with the desired and expected result of that step.
Scherlis and Scott, considering the issue of program verification, have probably had some similar idea in mind, writing, in their interesting work, (Scherlis and Scott 1983): "But, even relatively elementary programs tend to be more complicated than elementary theorems. Why? Because in a certain sense more of their structure has to be made more explicit. In mathematical literature, it is often sufficient to do one precise calculation, and for the other cases say 'similarly'. A proof is often more a genteel tourist guide than instructions for a treasure hunt. Programs, on the other hand, not only operate on very highly structured data, but they must do so in unobvious ways in order to be efficient."
See the aforementioned in the previous footnote, (Scherlis and Scott 1983).
Computing errors do happen, as said, and so faults of computing system are not rare at all. But here we consider "disasters" as faults which result in harsh damage, such as death, severe injury, or grave financial loss. Such cases are very uncommon. See, e.g., (MacKenzie 2001, pp. 299–301; TRD 2009).
References
Asperti, A., Geuvers, H., & Natarajan, R. (2009). Social processes, program verification and all that. Mathematical Structures in Computer Science, 19(5), 877–896.
Auslander, J. (2008). On the roles of proof in mathematics. In B. Gold & R. A. Simons (Eds.), Proof and other dilemmas: Mathematics and philosophy (pp. 61–77). Washington: Mathematical Association of America.
Bjørner, D. (2006). Software engineering 1: Abstraction and modelling. An EATCS Series. Berlin: Springer.
Bloor, D. (1994). What can the sociologist of knowledge say about 2 + 2=4? In P. Ernest (Ed.), Mathematics, education and philosophy: An international perspective (pp. 15–26). London: Falmer Press.
Cockburn, A. (2004). The end of software engineering and the start of economic-cooperative gaming. Computer Science and Information System, 1(1), 1–32.
Colburn, T. R., Fetzer, J. H., & Rankin, T. L. (Eds.). (1993). Program verification: Fundamental issues in computer science. Dordrecht: Kluwer Academic Publishers.
Collins, H. (1990). Artificial experts: Social knowledge and intelligent machines. Cambridge: Cambridge University Press.
Crowe, M. J. (1988). Ten misconceptions about mathematics and its history. In W. Aspray & P. Kitcher (Eds.), History and philosophy of modern mathematics (pp. 260–277). Minneapolis: University of Minnesota Press.
Davis, P. J. (1972). Fidelity in mathematical discourse: Is one and one really two? American Mathematical Monthly, 79(3), 252–263.
De Millo, R. A., Lipton, R. J., & Perlis, A. J. (1979). Social processes and proofs of theorems and programs. Communications of the ACM, 22(5), 271–280.
Detlefsen, M. (Ed.). (1992). Proof and knowledge in mathematics. London: Routledge.
Ernest, P. (1991). The philosophy of mathematics education. London: Falmer Press.
Fetzer, J. H. (1988). Program verification: The very idea. Communications of the ACM, 31(9), 1048–1063.
Giaquinto, M. (2005). Mathematical activity. In P. Mancosu, K. F. Jorgensen, & S. A. Pedersen (Eds.), Visualization explanation and reasoning styles in mathematics (pp. 75–87). Dordrecht: Springer.
Harel, D. (with Feldman Y.) (2004). Algorithmics: The spirit of computing, 3rd ed. Reading: Addison-Wesley.
Hersh, R. (1997). What is mathematics, really? Oxford: Oxford University Press.
Hoare, C. A. R. (1969). An axiomatic basis for computer programming. Communications of the ACM 12(10), 576–580, 583.
Hoare, C. A. R. (1986). Mathematics of Programming. BYTE (August). Reprinted in Colburn, T. R., Fetzer, J. H., & Rankin, T. L. (Eds.) (1993) (pp. 135–154).
Kitcher, P. (1984). The nature of mathematical knowledge. Oxford: Oxford University Press.
Liskov, B., & Zilles, S. (1977). An introduction to formal specifications of data abstractions. In R. T. Yeh (Ed.), Current trends in programming methodology (pp. 1–32). Englewood Cliffs: Prentice Hall.
MacKenzie, D. (2001). Mechanizing proof: Computing, risk, and trust. Cambridge: Cambridge University Press.
MacKenzie, D. (2005). What in the name of Euclid is going on here? Science, 207(5714), 1402–1403.
Mancosu, P. (2000). On mathematical explanation. In E. Grosholtz & H. Berger (Eds.), Growth of mathematical knowledge (pp. 103–120). Dordrecht: Kluwer Academic Publishers.
Maurer, W. D. (1979). Letter to the editor. Communications of the ACM, 22, 625–629.
Pelaez, E. (1988). A Gift from Pandora’s Box: The Software Crisis. Ph.D. dissertation. Edinburgh: University of Edinburgh.
Pigden, C. R. (1987). Two dogmatists. Inquiry, 30(1), 173–193.
Putnam, H. (1962). It Ain’t necessarily so. Journal of Philosophy, 59, 658–671.
Putnam, H. (2002). The collapse of the fact/value dichotomy. Cambridge: Cambridge University Press.
Quine, W. V. O. (1951). Two dogmas of empiricism. Philosophical Review, 60, 20–43.
Rapaport, W. J. (2007). Can Programs Be Verified? http://www.cse.buffalo.edu/~rapaport/510/canprogsbeverified.html.
Resnik, M., & Kushner, D. (1987). Explanation, independence and realism in mathematics. British Journal for the Philosophy of Science, 38, 141–158.
Rota, G. C. (1997). The phenomenology of mathematical proof. Synthese, 111, 183–196.
Sandborg, D. (1998). Mathematical explanation and the theory of why-questions. British Journal for the Philosophy of Science, 49, 603–624.
Sasaki, C. (2005). What are revolutions in mathematics? And how do they differ from those in the natural sciences? Lecture given in Peking University. http://www.phil.pku.edu.cn/documents/Revolutions_in_Math.1.rtf.
Schach, S. R. (2007). Algorithmics: Object-oriented and classical software engineering (7th ed.). New York: McGraw-Hill.
Scherlis, W. L., & Scott, D. S. (1983). First steps towards inferential programming. In R. E. A. Mason (Ed.), Information processing 83 (pp. 199–212). Amsterdam: Elsevier Science Publishers.
Shapiro, S. (2000). Thinking about mathematics: The philosophy of mathematics. Oxford: Oxford University Press.
Simons, C. L., Parmee, I. C., & Coward, P. D. (2003). 35 years on: To What extent has software engineering design achieved its goals? IEE Proceedings–Software, 19(5), 337–350.
Smith, B. C. (1985). Limits of correctness in computers. As center for the study of language and information report No. CSLI-85–36. Stanford: Ventura Hall.
Steiner, M. (1978). Mathematical explanation. Philosophical Studies, 34, 131–151.
Thurston, W. P. (1994). On proof and progress in mathematics. Bulletin of the American Mathematical Society, 30, 161–171.
TRD, (2009). The risks digest—Forum on risks to the public in computers and related systems, regularly updated. http://catless.ncl.ac.uk/risks.
Tymoczko, T. (1979). The four-color problem and its philosophical significance. Journal of Philosophy, 76, 57–83.
Zemanek, H. (1979). Abstract architecture. In D. Bjørner (Ed.), Abstract software specifications (pp. 1–42). Copenhagen: Springer.
Acknowledgments
This paper is based on work which has been carried out while I was a doctoral student at The Cohn Institute for The History and Philosophy of Sciences and Ideas, Tel-Aviv University. I wish to thank Leo Corry for his help and comments.
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
About this article
Cite this article
Pincas, U. Program Verification and Functioning of Operative Computing Revisited: How about Mathematics Engineering?. Minds & Machines 21, 337–359 (2011). https://doi.org/10.1007/s11023-011-9237-z
Received:
Accepted:
Published:
Issue Date:
DOI: https://doi.org/10.1007/s11023-011-9237-z