On malfunctioning software.
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, whet...
| Publicado en: | Synthese Vol. 192; no. 4; pp. 1199 - 1221 |
|---|---|
| Autores principales: | , , |
| Formato: | Artículo |
| Publicado: |
Springer Nature
Apr2015
|
| Materias: | |
| Acceso en línea: | Ver este registro en EBSCOhost |
| fields | @attributes: recordID: 1 pdfLink: plink: https://search.ebscohost.com/login.aspx?direct=true&db=hlh&AN=102498087&site=ehost-live header: @attributes: shortDbName: hlh uiTerm: 102498087 longDbName: Humanities International Complete uiTag: AN controlInfo: bkinfo: jinfo: jid: 00397857 4LI jtl: Synthese issn: 00397857 maglogo: N pubinfo: dt: Apr2015 vid: 192 iid: 4 pid: 237 pub: Springer Nature artinfo: ui: 102498087 10.1007/s11229-014-0610-3 ppf: 1199 ppct: 22 formats: fmt: @attributes: type: P size: 491KB tig: atl: On malfunctioning software. aug: au: Floridi, Luciano Fresco, Nir Primiero, Giuseppe affil: Oxford Internet Institute, University of Oxford, 1 St Giles Oxford OX1 3JS UK Sidney M. Edelstein Centre, The Hebrew University of Jerusalem, Jerusalem Israel Department of Computer Science, Middlesex University, London UK su: Computer software Manufacturing processes Manufacturing defects Design defects Notions (Philosophy) sug: subj: Computer software Manufacturing processes Manufacturing defects Design defects Notions (Philosophy) keyword: Artefact Design Dysfunction Function Misfunction Software ab: 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 (sometimes) or cannot (ever) 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. pubtype: Academic Journal doctype: Article src: R language: English refInfo: copyright: @attributes: flag: Y custom: Synthese is a copyright of Springer, 2015. All Rights Reserved. item: Synthese holder: Springer Nature dt: @attributes: year: 2015 holdings: @attributes: islocal: N |
|---|