Software is a ubiquitous artifact, yet not much has been done to understand its ontological nature. There are a few accounts offered so far about the nature of software. I argue that none of those accounts give a plausible picture of the nature of software. I draw attention to the striking similarities between software and musical works. These similarities motivate to look more closely on the discussions regarding the nature of the musical works. With the lessons drawn from the ontology (...) of musical works I offer a novel account of the nature of software. In this account, software is an abstract artifact. I elaborate the conditions under which software comes into existence; how it persists; how and on which entities its existence depends. (shrink)

Turner argues that computer programs must have purposes, that implementation is not a kind of semantics, and that computers might need to understand what they do. I respectfully disagree: Computer programs need not have purposes, implementation is a kind of semantic interpretation, and neither human computers nor computing machines need to understand what they do.

There are many branches of philosophy called “the philosophy of X,” where X = disciplines ranging from history to physics. The philosophy of artificial intelligence has a long history, and there are many courses and texts with that title. Surprisingly, the philosophy of computer science is not nearly as well-developed. This article proposes topics that might constitute the philosophy of computer science and describes a course covering those topics, along with suggested readings and assignments.

Artefacts do not always do what they are supposed to, due to a variety of reasons, including manufacturing problems, poor maintenance, and normal wear-and-tear. Since software is an artefact, it should be subject to malfunctioning in the same sense in which other artefacts can malfunction. Yet, whether software is on a par with other artefacts when it comes to malfunctioning crucially depends on the abstraction used in the analysis. We distinguish between “negative” and “positive” notions of malfunction. A negative malfunction, (...) or dysfunction, occurs when an artefact token either does not or cannot do what it is supposed to. A positive malfunction, or misfunction, occurs when an artefact token may do what is supposed to but, at least occasionally, it also yields some unintended and undesirable effects. We argue that software, understood as type, may misfunction in some limited sense, but cannot dysfunction. Accordingly, one should distinguish software from other technical artefacts, in view of their design that makes dysfunction impossible for the former, while possible for the latter. (shrink)

This paper offers a review of Giuseppe Primero’s (2020) book “On the foundations of computing”_._ Mathematical, engineering, and experimental foundations of the science of computing are examined under the light of the notions of formal, physical, and experimental computational validity provided by the author. It is challenged the thesis that experimental computational validity can be defined only for the algorithmic method and not for the software development process. The notions of computational hypothesis and computational experiment provided by Primiero (2020) are (...) extended to the case of software development. Finally, it is highlighted how the hypothetical-deductive method is involved in the practice of using models to corroborate computational hypotheses in software testing. As a concluding remark, it is underlined how defining experimental computational validity in the context of software development offers a sound experimental foundation to the science of computing. (shrink)