On Malfunctioning Software

Floridi, Luciano; Fresco, Nir; Primiero, Giuseppe

doi:10.2139/ssrn.3839344

Cited by 6 publications

(14 citation statements)

References 9 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

“…Testing the software then provides new evidence and the Bayes' theorem prescribes how probabilities are to be changed in light of this new evidence. 18 The fact that running the exact same test twice does not improve the probability of correctness, is already accounted for by the Bayes' theorem. So what we need is a way of finding relevant tests that do increase the probability.…”

Section: Lesson 8: Learning From Philosophy Of Science and Mathematicsmentioning

confidence: 99%

“…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].…”

mentioning

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

“…3. we revisit the mentioned theory of software malfunctioning from [15] in the light of the above results;…”

Section: Introductionmentioning

confidence: 96%

“…In [15], the authors perform a conceptual analysis of the problem of miscomputation, extending the existing literature in the philosophy of technology on the problem of misfunctioning for non-computational artefacts. This tradition has already played an important role in providing taxonomical formats and policy advice on errors of functioning in the technological context.…”

Section: Introductionmentioning

confidence: 99%

On Malfunction, Mechanisms and Malware Classification

2018

Self Cite

View full text Add to dashboard Cite

Malware has been around since the 1980s and is a large and expensive security concern today, constantly growing over the past years. As our social, professional and financial lives become more digitalized, they present larger and more profitable targets for malware. The problem of classifying and preventing malware is therefore urgent and it is complicated by the existence of several specific approaches. In this paper, we use an existing malware taxonomy to formulate a general, language independent functional description of malware as transformers between states of the host system and described by a trust relation with its components. This description is then further generalised in terms of mechanisms, thereby contributing to a general understanding of malware. The aim is to use the latter in order to present an improved classification method for malware.

show abstract

On Malfunctioning Software

Cited by 6 publications

References 9 publications

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

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

Miscomputation in software: Learning to live with errors

On Malfunction, Mechanisms and Malware Classification

Contact Info

Product

Resources

About