On malfunctioning software

Floridi, Luciano; Fresco, Nir; Primiero, Giuseppe

doi:10.1007/s11229-014-0610-3

Cited by 37 publications

(35 citation statements)

References 33 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Second, it may misfunction, e.g. by producing unintended or undesired (side-)effects (Floridi et al, 2015;Mittelstadt et al, 2016) that are deemed to be societally or ethically unacceptable (outcome malfunction). Related to dysfunction is a first category of explanations.…”

Section: Explanationmentioning

confidence: 99%

Explanation Methods in Deep Learning: Users, Values, Concerns and Challenges

Ras¹,

Gerven²,

Haselager³

2018

The Springer Series on Challenges in Machine Learning

137

107

View full text Add to dashboard Cite

show abstract

Section: Explanationmentioning

confidence: 99%

Explanation Methods in Deep Learning: Users, Values, Concerns and Challenges

Ras¹,

Gerven²,

Haselager³

2018

The Springer Series on Challenges in Machine Learning

137

107

View full text Add to dashboard Cite

show abstract

“…7 As discussed by Northrop et al [38], challenges of ultra-large-scale systems often need to be seen through this wider perspective. 8 A discussion along these lines followed in response to Primiero and Fresco [19]; Dewhurst [15] argues that design errors should not be seen as miscomputation and Floridi et al [18] discusses whether software can be seen as artifacts that can malfunction. 9 Epsilon refers to the concept of concept stretching of Lakatos [31].…”

Section: Lesson 3: Classifying Kinds Of Miscomputationmentioning

confidence: 99%

Miscomputation in software: Learning to live with errors

Petříček

2017

Programming

View full text Add to dashboard Cite

Computer programs do not always work as expected. In fact, ominous warnings about the desperate state of the software industry continue to be released with almost ritualistic regularity. In this paper, we look at the 60 years history of programming and at the different practical methods that software community developed to live with programming errors.We do so by observing a class of students discussing different approaches to programming errors. While learning about the different methods for dealing with errors, we uncover basic assumptions that proponents of different paradigms follow. We learn about the mathematical attempt to eliminate errors through formal methods, scientific method based on testing, a way of building reliable systems through engineering methods, as well as an artistic approach to live coding that accepts errors as a creative inspiration.This way, we can explore the differences and similarities among the different paradigms. By inviting proponents of different methods into a single discussion, we hope to open potential for new thinking about errors. When should we use which of the approaches? And what can software development learn from mathematics, science, engineering and art?When programming or studying programming, we are often enclosed in small communities and we take our basic assumptions for granted. Through the discussion in this paper, we attempt to map the large and rich space of programming ideas and provide reference points for exploring, perhaps foreign, ideas that can challenge some of our assumptions. ACM CCS 2012General and reference → Surveys and overviews;Social and professional topics → History of computing; The history and classification of errorsIf trials of three or four simple cases have been made, and are found to agree with the results given by the engine, it is scarcely possible that there can be any error among the cards [5].The opening quote from Charles Babbage about the Analytical Engine suggests that Babbage did not see errors as a big problem. If that was the case, the software industry would save billions of dollars, but sadly, eradicating all software errors turned out to be harder than expected.In retrospect, it is curious to see how long it took early computer personnel to realise that coding errors are a problem. One of the first people to realize that " [he] was going to spend a good deal of [his] time finding mistakes that [he] had made in [his] programs" was Maurice Wilkes in late 1940s [17]. However, as Mark Priestley writes, a typical comment [circa 1949] was that of Miller, who wrote that such errors, along with hardware faults, could be "expected, in time, to become infrequent" [41]. While hardware faults did become relatively infrequent, the same cannot be said about coding errors.Over the next 20 years, computers developed from a research experiment into an ordinary scientific tool and industrial instrument. As noted by Nathan Ensmenger, by the end of 1960s many were talking of a computing crisis. For the next "several decades, managers, academic...

show abstract

“…To show that this is the case, it is essential to illustrate how such identity is preserved at each level of abstraction in the ontology of computing mechanisms. 15 The multi-layered analysis of computational systems, reliant on the practice of computer scientists and philosophically advocated since at least [26], is essential to the mechanistic explanation of physical computing [60], as well as to the identification of their malfunctioning [31,28]. For the present purposes, it is sufficient to apply the analysis of abstract information for computational systems offered in [63].…”

Section: Computational Intelligence Is Implementation Neutralmentioning

confidence: 99%