nach oben

2018 | Buch

Kapitel lesen Erstes Kapitel lesen

Computational Artifacts

Towards a Philosophy of Computer Science

verfasst von: Dr. Raymond Turner

Verlag: Springer Berlin Heidelberg

Enthalten in: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Einloggen, um Zugang zu erhalten

Über dieses Buch

The philosophy of computer science is concerned with issues that arise from reflection upon the nature and practice of the discipline of computer science. This book presents an approach to the subject that is centered upon the notion of computational artefact. It provides an analysis of the things of computer science as technical artefacts. Seeing them in this way enables the application of the analytical tools and concepts from the philosophy of technology to the technical artefacts of computer science.

With this conceptual framework the author examines some of the central philosophical concerns of computer science including the foundations of semantics, the logical role of specification, the nature of correctness, computational ontology and abstraction, formal methods, computational epistemology and explanation, the methodology of computer science, and the nature of computation.

The book will be of value to philosophers and computer scientists.

Inhaltsverzeichnis

Frontmatter

Part I

Frontmatter

Chapter 1. Computer Science

Abstract

The philosophy of computer science [233] is intended to stand to computer science as the philosophies of mathematics [121], biology [95], and technology [75] stand to their respective disciplines. These are instances of what Stuart Shapiro [215] calls the philosophy of X disciplines, and any philosophical investigation of such subjects must begin with some discussion of the discipline itself. In particular, it must aim to expose its subject matter, uncover its core activities, and draw out its distinctive features.

Raymond Turner

Chapter 2. Towards a Philosophy of Computer Science

Abstract

Any philosophy of computer science [233] must describe and categorize the nature of its entities. In this regard, via their semantic definitions, the formal languages of the discipline somehow govern the subject’s ontology. Consequently, some attention must be given to the nature of these semantic accounts, and how they fix or contribute to the kinds of entity dealt with. Furthermore, any statement of the goals of computer science will highlight its methods of reaching those goals, its methodology. This will bring to the fore its claims to knowledge, its epistemology. And, while addressing these issues, we must assess if computer science raises any distinctive philosophical concerns.

Raymond Turner

Part II

Frontmatter

Chapter 3. Computational Artifacts

Abstract

Technical artifacts are taken to include all the common objects of everyday life, such as chairs, televisions, paper clips, telephones, smartphones and dog collars. They are material objects, the engineered things of world that have been intentionally produced by humans in order to fulfill a practical function.

Raymond Turner

Chapter 4. Logic Machines as Technical Artifacts

Abstract

Languages and machines represent the two ends of the computational spectrum: the abstract and the physical. They come together at the digital interface, the very lowest level in the computational realm. Digital circuits are employed to store, communicate, and manipulate data. Flip-ops, counters, converters, and memory circuits are common examples.

Raymond Turner

Chapter 5. The Ontology of Programs

Abstract

The ontological standing of programs has been the subject of some debate in the relatively small amount of philosophical literature that concerns mainstream computer science. In particular, much of this literature would have it that programs have both a symbolic or abstract representation and a physical manifestation.

Raymond Turner

Chapter 6. Software Systems as Technical Artifacts

Abstract

Our institutions and organizational structures, whether in government, commerce, industry, or education, are underpinned and controlled by software systems. So are our laptops, televisions, cars, and mobile phones. In this chapter we present a conceptualization of them as technical artifacts.

Raymond Turner

Part III

Frontmatter

Chapter 7. The Languages of Computer Science

Abstract

Throughout their construction process computational artifacts are defined, specified, and described by the languages of computer science. This is one of their distinctive features. Artificial languages are employed for programming, specification, and architectural and hardware description. They are the vehicles for the expression of their functional and structural requirements.

Raymond Turner

Chapter 8. Programming Languages

Abstract

Without programming languages, machines would be idle devices much like cars without drivers or hairdressers without combs. In this chapter, we provide a guide to their definitions, and their containing paradigms. This will serve as background to one of the main objectives of this section of the book, namely to explore the semantic issues that surround programming languages.

Raymond Turner

Chapter 9. Semantic Theories

Abstract

Aside from its syntax, a programming language must also be given a semantic definition and an implementation. Without a semantic definition, we could not compute by hand; without an implementation, there would be no mechanical computation. These three ingredients, syntax, semantics, and implementation, are all necessary, and work together to define a programming language.

Raymond Turner

Chapter 10. Formal Semantics

Abstract

In this chapter we look more carefully at the various forms of semantic de_nition [26, 68, 92, 97, 114, 141, 167, 173, 189, 204, 213, 218, 219, 224, 251, 246]. These range from natural language accounts through to mathematical ones of various kinds and avors. We shall attempt to evaluate the various approaches to semantics against the criteria set out in the previous chapter. In this regard, we shall explore the di_erent roles of operational and denotational approaches.

Raymond Turner

Chapter 11. Semantics and Implementation

Abstract

Programming language implementations are complex pieces of software and hardware that provide paradigm instances of computational systems. Actual implementations are often separated into phases involving syntax analysis, compilation, and interpretation [8], and involve layers of translation before a concrete representation is reached through direct interpretation.

Raymond Turner

Chapter 12. Specification Languages

Abstract

Specification is a heterogeneous enterprise with layers of complexity, generality and degrees of detail. In practice, specifications are expressed in a host of languages and formalisms. These range from the vernacular through to specialized specification languages. Some of them are graphical in content (e.g., portions of UML), and many others are based upon some logical notation. There are also algebraic approaches that employ algebraic or model-theoretic structures.

Raymond Turner

Part IV

Frontmatter

Chapter 13. Software System Methodology

Abstract

Software systems give computer science its practical potency. Physical library systems, banking systems, and management systems and structures existed before the advent of the computer. Libraries have always issued books, and banks have always taken our money. But, with the advent of the computer, these systems have been modeled in software. Indeed, the latter models are not just computational models of existing physical systems, but have been digitally enhanced and enriched.

Raymond Turner

Chapter 14. Specification

Abstract

In this chapter, we consider the nature and methodological concerns of requirements elicitation and speci_cation. These activities raise a collection of overlapping conceptual questions and problems [235].

Raymond Turner

Chapter 15. The Philosophy of Design

Abstract

Design [16] is everywhere in computer science. It occurs in the design of software both at the level of overall system design [9] and in the design of individual programs [93]. For simple programs, the activity of design may be implicit. But design decisions are, or have been, taken even in the most straightforward cases. For example, any programmer who chooses quicksort instead of mergesort has taken a design decision. More demandingly, it occurs when the programmer moves from a given specification to a program that she has never constructed before. For large systems, design decisions about the overall structure of a system, its parts, and how its functional demands are to be met take place long before any code is cut.

Raymond Turner

Chapter 16. Simplicity

Abstract

One of the cornerstones of program and software design centers on the opposing notions of simplicity and complexity. Simplicity is said to aid transparency and reliability in design. So say professional computer scientists of all avors. All put simplicity at the core of good and successful design.

Raymond Turner

Chapter 17. Modularity

Abstract

One of the methods advocated for achieving simplicity in design, for avoiding complexity, is modularization. Modular, structured, and object-oriented programming all aim at the construction of large programs and software systems by decomposition into smaller pieces [55]. Complexity is addressed by the separation of concerns: by decomposing a problem into smaller units, the complexity of individual units is reduced. Modularization is taken to increase the likelihood of correct designs: smaller units, when correct, are more transparently so. Presumably, as a result of breaking a problem into smaller units, the solutions to such units have a better chance of being elegant and parsimonious.

Raymond Turner

Chapter 18. Formal Methods

Abstract

Formal methods employ mathematical models to design software and hardware systems, and they employ mathematical proofs in an attempt to guarantee correctness.

Raymond Turner

Chapter 19. The Design of Programming Languages

Abstract

Good programming depends upon well-designed programming languages, and this has been recognized from the beginnings of the discipline. Indeed, the design of programming languages is one of the core activities of professional computer scientists. There are many properties that are taken to be necessary for a good design. Most critically, the language should aid the construction of well-designed and correct programs, and this leads to principles that more directly govern language design. However, we shall not try to provide a comprehensive overview and analysis of such design principles.

Raymond Turner

Chapter 20. Semantics and Design

Abstract

How do we design simple yet expressive languages? One piece of general advice about language design comes from one the founders of formal semantics, Christopher Strachey [219]:

Raymond Turner

Chapter 21. Data Abstraction

Abstract

Abstraction in all its forms has played a substantial role in the design of programming languages. It has motivated the various language paradigms, and has inspired, and is manifested in, the rich type structure and machinery of control to be found in contemporary languages. These include specification schemas, procedural abstraction, inheritance, iteration, recursion, polymorphism, abstract data types, modules, and classes. The quest for simpler yet richer means of abstraction is one of the central driving forces in language design. These language features both aid and constrain the style of programming and specification.

Raymond Turner

Part V

Frontmatter

Chapter 22. Computability

Abstract

The work of Turing and Church has had a profound inuence on the foundations and development of computer science. Church’s work on the lambda calculus not only provided one of the central mathematical accounts of computation, but also paved the way for the development of the functional paradigm, and the semantics of programming languages. Turing is regarded as providing the definitive account of computation, inspiring the design of early computers, and giving birth to artificial intelligence.

Raymond Turner

Chapter 23. Feasible Computations

Abstract

Computational artifacts must perform their function. Part of this involves constraints upon their practicality: programs should involve computations that can be carried out in a reasonable time using reasonable resources. But what is reasonable? Presumably, a program that on average takes more than the age of the universe to return its results is not reasonable.

Raymond Turner

Chapter 24. Varieties of Correctness

Abstract

When software does not work, does not conform to its speci_cation, it is said to be incorrect; it is said to contain mistakes or bugs. Some instances are infamous. Mistakes in the software controlling the radiation therapy machine Therac-25 had fatal consequences, mistakes in the guidance system software of Ariane 5 caused it to crash, and a mistake in AT&T’s software caused computer crashes.

Raymond Turner

Chapter 25. Program Correctness

Abstract

The mathematical notion of correctness links the symbolic program with its specification, where correctness involves the construction of a proof that the program meets its specification. In this chapter, our aim is to assess the nature of such proofs.

Raymond Turner

Chapter 26. Types and Correctness

Abstract

While in practice full correctness proofs are rarely forthcoming, computer scientists still employ tools that guarantee some form of correctness. One of these tools is a type checker for the language. Types fine-tune the grammatical structure of the language, and bring semantic intuitions to the grammatical party. The following is a quote from Pierce’s text on types in programming languages.

Raymond Turner

Chapter 27. THE SIMPLE MAPPING ACCOUNT

Abstract

We now move on to the second notion of correctness, that which governs physical devices. On the face of it, this raises a very different kind of conceptual problem from the mathematical one. Electronic devices fail for a variety of reasons: mechanical impact, excessive temperature, or very high voltage may all cause failure. How do we test such circuits for correctness? We have already indicated that some notion of verification is involved, but what form does it take? Here we are not referring to the use of formal techniques for establishing the correctness of the abstract digital circuit against its truth table specification [32].

Raymond Turner

Chapter 28. Computational Explanation

Abstract

A design contains an explanation of how an artifact realizes its function. But, how exactly? In particular, how are programmers and software engineers able to predict and explain the outcomes of their software designs before they have been implemented?

Raymond Turner

Chapter 29. Intention and Correctness

Abstract

The simple mapping account of correctness reduces correctness to extensional agreement. While we have indicated various means of cutting down the number of solutions, restricting them in some way, there is something more substantial missing from our account. An assumption underlying the simple mapping account is that computation and programming are notions that can be fully characterized independently of any intentions.

Raymond Turner

Chapter 30. Rule Following and Correctness

Abstract

Programming involves the construction of programs that meet their specifications. This draws in all the associated activities of programming such as testing, verification, and establishing correctness. And these are rule following activities.

Raymond Turner

Backmatter

Titel: Computational Artifacts
verfasst von: Dr. Raymond Turner
Verlag: Springer Berlin Heidelberg
Electronic ISBN: 978-3-662-55565-1
Print ISBN: 978-3-662-55564-4
DOI: https://doi.org/10.1007/978-3-662-55565-1