How computer programmers work : understanding software development in practise

ion in this sense means that the programming language does not closely describe what the machine does, but instead presents a symbolic notation – an abstraction – that is seen as easier to use. Abstract programming languages are considered to lead to a more natural way of thinking as well as being more productive, because the programmer has to write fewer lines of code.80 Conversely, assembly language and low-level programming languages are considered to lead to an unnatural style of programming: “Assembly . . . [is] forcing the programmer to think like the machine.”81 According to Stroustrup, a programming language is a vehicle for machine actions, plus concepts to use when thinking.82 This viewpoint is a variant of an underlying idea common to much of computer science: that a programming language is in some sense a way of thinking, and that abstraction is the ideal for thinking. Moreover, it is a common viewpoint that “every high-level language provides abstraction of machine services.”83 Combined with Stroustrup’s definition, this implies that a good, high-level programming language provides abstract concepts to think about machine actions that are themselves presented as abstractions.84 Jones writes that high-level programming 80Ibid. 81Ibid. p. 6. 82Stroustrup 1985 [1997] p. 9. 83Pierce 2002 p. 6. 84The general view described here is not exactly Stroustrup’s own position. He advocates that the programming language, sans the concepts for thinking, should be “close to the machine” i.e. non-abstract. Stroustrup 1985 [1997] p. 9. 3.2 mainstream programming theories 85 languages abstract away from any particular machine;85 this viewpoint of course works well with an orientation of research away from engineering and towards mathematics. The ideal of abstraction is not only applied to program code but also to the textbooks and articles that explain programming languages. To give an example, here is a textbook definition of what a type system is: “A type system is a tractable syntactic method for proving the absence of certain program behaviours by classifying phrases according to the kinds of values they produce.”86 The definition is so abstract and general that it hardly enlightens anyone who does not already know what a type system is. A definition in plain language could be: a type system is a mechanism in a programming language that makes sure that different kinds of values do not accidently get mixed up; for example numbers and letters, or integers and fractional numbers. According to the same textbook, the history of type systems begins in the 1870’s with Gottlob Frege’s works on formal logic.87 However, Frege did not have programming languages in mind: type systems were first introduced to programming languages in the 1950s for reasons of efficiency.88 To place the beginnings of type systems with Frege has the effect of maximising the emphasis on formal, logical, and mathematical aspects at the cost of downplaying practical aspects. Finally, we should note with caution that abstraction is sometimes given an unrealistic importance, as if “more abstract” is the same as “better”. In reality, to regard a program or programming language as abstract is simply a perspective. Any given program must run as concrete instructions on a concrete computer in order to be useful, no matter how “abstract” the programming language is. From the 85Filinski et al. 2005 chp. 1, p. 3. 86Pierce 2002 p. 1. 87Ibid. p. 11. 88Ibid. p. 8 f. 86 chapter 3. theory perspective of the machine that executes the program, the high-level programming language program is every bit as concrete as binary machine code – the layers of programs that make up a high-level programming language are perhaps thought of as abstractions, but they exist in a concrete form. 3.2.3.4 Machine-orientation Despite, or perhaps because of, the emphasis placed on mathematics and logic in computer science, the thinking is remarkably oriented towards the machines, meaning that the world is seen almost exclusively in terms of what the computers can do, rather than what people do. We read in a quote above that “Reasoning about situations means constructing arguments about them; we want to do this formally, so that the arguments are valid and can be defended rigorously, or executed on a machine.”89 This quote can also be read as indicating that computer scientists should work with formal systems precisely because they can be executed by a machine. Thus, the notion of an abstract machine comes to dictate the focus of computer science. Within computer science, the study of programming languages is generally divided into syntax and semantics, where syntax is the study of programming notation and semantics the study of the meaning of programs. This notion of meaning, however, includes only the mathematical formalization of a program, which is also what can be executed on a machine.90 The usual sense of semantics – which is the meaning a program has to a human – is lost. Paulson writes that an engineer understands a bicycle in terms of its components, and therefore a programmer should also understand a program in terms of components.91 This thinking is a kind of reification: mistaking concepts for concrete things. Machine-oriented thinking easily leads to this kind of philosophical mistake, because focusing solely on the machine means that the inherent ambiguity of human thinking is ignored. The comparison between bicycle and 89Huth & Ryan 2000 [2004] p. 1. 90Filinski et al. 2005 chp. 1, p. 2. 91Paulson 1991 [1996] p. 59. 3.2 mainstream programming theories 87 program is fine as a metaphor – if it is extended with additional explanation – but it cannot stand alone as an argument in itself. 3.2.3.5 Premises of argumentation There is within computer science an unfortunate tendency to ignore the premises of the mathematical systems upon which the research focuses. Naur calls it a pattern in ignoring subjectivity in computer science.92 By “subjectivity”, Naur largely means the consequences for the people who are to use the programs, that is, the programs’ usefulness. According to Naur, computer science publications commonly postulate a need for a new notation for some purpose. The notation is then presented in thorough technical details; next, it is claimed in the conclusion that the need is now met, without any evidence. As an example, we will look at the doctoral dissertation of Ulla Solin Animation of Parallel Algorithms from 1992. This is not badlyexecuted research – on the contrary, it is exemplary in fulfilling the expectations of a dissertation in computer science and precisely because of that it serves well as an example. In the introduction to the dissertation, Solin briefly explains what the subject is: making animations out of programs.93 She then proceeds in seven chapters to demonstrate a detailed method of constructing animated programs, complete with mathematical proof. The dissertation’s conclusion begins with the sentence: “It is obvious that animation has a wide range of potential use and should become an important tool for testing and analysing algorithms.”94 The problem is that it is not at all possible to conclude this from the dissertation, which concerns only the details of a solution to the problem that has been posed. The statement that animation should be an important tool is actually the direct opposite of a conclusion: it is the premise for the whole dissertation. Without assuming animation of programs to be important, it makes little sense to devote 92Naur 1995 p. 10. 93That is, making a computer-generated animated film clip out of a computer program to illustrate how that program is behaving. 94Solin 1992 p. 101. 88 chapter 3. theory a dissertation to it. Nor is it obvious that animation is as useful as claimed – as it is, history so far has shown that animating programs is not actually an important tool for programming.95 An example on a larger scale comes from Jones, who conducted research in automatic compiler generation since 1980.96 Twenty-five years later he writes that: “It is characteristic of our grand dream [of automatic compiler generation] that we are just now beginning to understand which problems really need to be solved.”97 However, Jones does not call for an examination of the premises of the dream, but rather advocates more mathematics: “What is needed is rather a better fundamental understanding of the theory and practice of binding time transformations . . . ”.98 The focus on mathematics and logic to the exclusion of the premises of research sometimes has the consequence that overly specialized subfields in computer science develop an unrealistic sense of their own importance. For example, Glynn Winskel, a researcher in the field of programming language semantics – which is the mathematical study of programming languages – writes that semantics is useful for “various kinds of analysis and verification” and can also reveal “subtleties of which it is important to be aware.”99 Moreover, semantics is arguably not of great practical use, since “it is fairly involved to show even trivial programs are correct.” 100 Overall, this does not give the impression that semantics is a field of extreme importance for the whole of computer science. Yet the fact that program semantics is regarded as belonging to the foundations of computer 95It is not for want of trying. So-called visual programming is a long-standing idea held by computer scientists. See for example the August 1985 issue of IEEE Computer magazine devoted to “Visual Programming”, including an article on “Animating Programs Using Smalltalk”. 96Jones & Schmidt 1980: “Compiler Generation from Denotational Semantics.” 97Filinski et al. 2005 chp. 1, p. 22. 98Ibid. 99Winskel 1993 p. xv. 100Ibid. p. 95. 3.2 mainstream programming theories 89 science101 indicates the emphasis placed upon the mathematical perspective. 3.2.3.6 Work processes We will now look at what computer science has to sa