DOCSLIB.ORG

Concurrent Programming Concepts Invented, Program

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Concurrent Programming Concepts Invented, Program Concurrent Programming Concepts Per Brinch Hansen Information California Institute of Technology, Pasadena, California 91109 This paper describes the evolution of language features for multiprogramming from event queues and semaphores to critical regions and monitors. It suggests that the choice of language concepts shouldbe guided by two simple principles : First, it should be possible to understand a concurrent program in time- independent terms by an effort proportional to its size; secondly, it should be possible to state assumptions about invariant relationships among program components and have these assumptions checked automatically. The central problems of multiprogramming are illustrated by annotated algorithms written in a well-structuredprogramming language. Key words and phrases: structured multiprogramming, programming languages, operating systems, programming errors, resource protection, compile-time checking, correctness proofs, sequential and concurrent processes, synchronizing events, semaphores, shared data, mutual exclusion, critical regions, monitors. CR categories: 4.22, 4.31, 4.32, 5.24 Somewhere there are decisions made that are programming systems. The techniques used not rational in any sense, that are subject to to implement these language concepts, which nothing more than the personal bias of the apply single-processor and decision maker. Logical methods, at best, re- both to multi- arrange the way in which personal bias is to processor systems, are described elsewhere. be introduced into a problem. Of course, this [1] "at best" is rather important. Present intuitive When a new programming technique, such methods unhappily introduce personal bias in as multiprogramming, is program- such a way that it makes problems impossible invented, to solve correctly. Our purpose must be to re- mers will initially use it in a completelyun- pattern the bias, so that it no longer interferes restricted manner to discover its potential. in this destructive way with the process of At a later stage, when experience with its design, and no longer inhibits clarity of form. practical limitations has been gained, de- Chistopher Alexander, Notes on the Synthesis a ofForm signers begin to recognize the benefits of more restrictive language notation which clarifies their own understanding of pro- 1. INTRODUCTION grams and enables compilers to detect seri- ous errors. This paper describes an attitude toward This survey describes the evolution of lan- multiprogramming—the programming tech- guage features for multiprogramming during niques used to control concurrent activities the past decade. I view this development by computers.* It tries to identify abstract mainly gradual shift from concepts that properties as a of programming languages that have a strong resemblance to assembly lan- facilitate the design of large,reliable multi- guage features toward a notation that en- * In this paper, the term multiprogramming is used courages hierarchical structuring of pro- consistently to denote all programming techniques grams. Several useful proposals are not used to control concurrent processes on single- processor aswell as multiprocessorsystems. mentioned here, and those that are included Computing Surveys, Vol. 5, No. December 1973 Science, 4, 224 Per Brinch Hansen Concurrent Programming Concepts CONTENTS are only meant to illustrate a general atti- and variables) and operations on data (rep- The following assertions will hold before tude toward the subject. resented by statements). During the execu- the execution of lines 1-8,respectively. The central problems of multiprogram- tion of the program, the operations are car- comment 1 0 out of n records processed ming are illustrated by algorithms written ried out strictly one at a time, and each (where 0 n) ; in a high-level language.I have included in- operation is completed within a finite time. comment 2 i out of n records processed formal assertions in the algorithms and out- The result of an operation can be defined by (where 0 i n) ; lined arguments of their correctness to show assertions about the relationships of data comment 3 i out of n records processed 1. Introduction 223 that multiprogramming concepts can be de- before and after its execution. (where 0 i < n) ; 2. SequentialProcesses 224 fined as concisely as sequential program- In Algorithm 1, we can make the following comment 4 i out of n records processed 3. Unrestricted Concurrency 226 ming concepts. In many ways, this survey assertions about the state of the (where 4. Structured Concurrency228 variables 0 i < n), and this = input 5. Disjoint Processes 230 can be regarded as an expanded version of before and after the execution of the input record Ri + 1 ; 6. Time-DependentErrors 231 an earlier paper [2]. We will begin with a statement in line 3: comment i out n processed 7. Timing Signals233 5 of records brief characterization of sequential pro- comment 3 i n 8. Critical Regions 236 out of records processed (where 0 i < n) , and this = updated 9. Critical Regions 241 grams. (where 0 i < n) ; record Ri + 1 ; 10. Conclusion 244 get (this, reader) comment 6 out Acknowledgements244 ; i + 1 of n records proc- Bibliography 244 comment 4 i out of n records processed essed (where 0 i < n) ; 2. SEQUENTIAL PROCESSES (where 0 i < n), and this = input comment 7 i out of n records processed record Ri 1; (where 0< i n) ; Although most programmers an + have intui- Sequential programs have two prop- comment 8 n out n processed understanding vital of records tive of what a sequential erties : (where 0 n) ; is, it may be useful to illustrate this s^ process 1) The a sequential program is Once the individual- statements are under- concept by an example.Algorithm 1 defines effect of independent of its speed execution. All stood, one can define the effect of a sequence a sequential that inputs fixed of process a that matters is that operations are of by a single pair RI, R2, ,Rn carried statements of assertions. number of records . from out one at a time with positive speed, and As an example, the body of the while sequential updates these state- one file, records, that certain relationships hold before and ment in Algorithm 1 can outputs them on another sequential file. be defined as a and after their execution. The time-independent single operation by means of the following The language notation is borrowed from behavior of sequential programs enables the assertions: are two Pascal. [3] The files declared as user to ignore details over which he has comment 3 each consist- no i out of n records processed variables, reader and printer, control (such as the schedulingpolicy (where 0 i n) of type T of the < ; ing of a sequence of records some operating system and the precise timing of process nextrecord and increment i by (declaredelsewhere) A type can . record of T operations carried out by processors pe- one; from and be appended to or removed a sequence ripherals). comment 7 i out n put of records processed by means of two standard procedures, 2) A sequentialprogram delivers the same (where 0< i n) ; and get. The current record is kept in a vari- result each time it is executed with a given The next step of simplification is to re- of type T. The variable i counts able, this, set of input data. The reproducible behavior duce the while statement to a single opera- processed; can as- the number of records it of sequential programs under any tion: 0 to n. circum- sume integer values from stances particularly comment 2 i out n records processed Algorithm 1 Sequential file updating is important for pro- of gram validation. It enables one to isolate (where 0 i n) ; var reader, printer: sequence of T; and correct program errors by systematic process the remaining n-i records; this: T; i: 0. n; testing. comment 8 n out of n records processed (where begin These properties of sequential programs 0 n) ; Finally, the (1) i:=0; are so well known that we tend to take them whole programcan be defined as a single operation: (2) while i<n do for granted. But as we shall see, these prop- (3) get (this, reader) ; erties can only be comment 1 0 out of n records processed maintained for multipro- (where 0 n) (4) update (this) ; gramming systems by a ; careful selection of process n Copyright © 1973, Association for Computing (5) put (this, printer) ; language concepts. records; Machinery, Inc. General permission to republish, (6) i l; comment 8 n out n records processed i: = + Algorithm 1 is a well-structured program of but not for profit, all or part of this material is (7) (where 0 n) ; is end that can be analyzed granted, provided that ACM's copyright notice in a step-wise manner At this point, only what the program does as given and that reference is made to this publica- (8) end as a set of nested operations. At the most a whole, is relevant, but the details of how tion, to its date of issue, and to the fact that re- The program defines a sequential process detailed level, the program printing privileges were grantedby permission of can be described it is done are irrelevant. The possibility of by constants in the Association for Computing Machinery. in terms of data (represented terms of assertions about each statement. replacing complex descriptions by partial Computing Surveys, Vol. 5, No. December 1973 Computing Surveys, Vol. 5, No. December 1973 225 Conditional 4, 4, 226 Per Brinch Hansen Concurrent Programming Concepts 227 tain functional aspects of it can be described start task do SI tions. Algorithm 2 is deliberately written in in even more economical terms. This is the an unstructured manner that makes it diffi- whole purpose of structured programming! will start the execution of statement SI as cult to understand. A well-structured algo- It is also essential to use hierarchical a new process.
Load more

Recommended publications
  • 7. Control Flow First?
    Copyright (C) R.A. van Engelen, FSU Department of Computer Science, 2000-2004 Ordering Program Execution: What is Done 7. Control Flow First? Overview Categories for specifying ordering in programming languages: Expressions 1. Sequencing: the execution of statements and evaluation of Evaluation order expressions is usually in the order in which they appear in a Assignments program text Structured and unstructured flow constructs 2. Selection (or alternation): a run-time condition determines the Goto's choice among two or more statements or expressions Sequencing 3. Iteration: a statement is repeated a number of times or until a Selection run-time condition is met Iteration and iterators 4. Procedural abstraction: subroutines encapsulate collections of Recursion statements and subroutine calls can be treated as single Nondeterminacy statements 5. Recursion: subroutines which call themselves directly or indirectly to solve a problem, where the problem is typically defined in terms of simpler versions of itself 6. Concurrency: two or more program fragments executed in parallel, either on separate processors or interleaved on a single processor Note: Study Chapter 6 of the textbook except Section 7. Nondeterminacy: the execution order among alternative 6.6.2. constructs is deliberately left unspecified, indicating that any alternative will lead to a correct result Expression Syntax Expression Evaluation Ordering: Precedence An expression consists of and Associativity An atomic object, e.g. number or variable The use of infix, prefix, and postfix notation leads to ambiguity An operator applied to a collection of operands (or as to what is an operand of what arguments) which are expressions Fortran example: a+b*c**d**e/f Common syntactic forms for operators: The choice among alternative evaluation orders depends on Function call notation, e.g.
    [Show full text]
  • Structured Programming - Retrospect and Prospect Harlan D
    University of Tennessee, Knoxville Trace: Tennessee Research and Creative Exchange The aH rlan D. Mills Collection Science Alliance 11-1986 Structured Programming - Retrospect and Prospect Harlan D. Mills Follow this and additional works at: http://trace.tennessee.edu/utk_harlan Part of the Software Engineering Commons Recommended Citation Mills, Harlan D., "Structured Programming - Retrospect and Prospect" (1986). The Harlan D. Mills Collection. http://trace.tennessee.edu/utk_harlan/20 This Article is brought to you for free and open access by the Science Alliance at Trace: Tennessee Research and Creative Exchange. It has been accepted for inclusion in The aH rlan D. Mills Collection by an authorized administrator of Trace: Tennessee Research and Creative Exchange. For more information, please contact [email protected]. mJNDAMNTL9JNNEPTS IN SOFTWARE ENGINEERING Structured Programming. Retrospect and Prospect Harlan D. Mills, IBM Corp. Stnuctured program- 2 ' dsger W. Dijkstra's 1969 "Struc- mon wisdom that no sizable program Ste red .tured Programming" articlel could be error-free. After, many sizable ming haxs changed ho w precipitated a decade of intense programs have run a year or more with no programs are written focus on programming techniques that has errors detected. since its introduction fundamentally alteredhumanexpectations and achievements in software devel- Impact of structured programming. two decades ago. opment. These expectations and achievements are However, it still has a Before this decade of intense focus, pro- not universal because of the inertia of lot of potentialfor gramming was regarded as a private, industrial practices. But they are well- lot of fo puzzle-solving activity ofwriting computer enough established to herald fundamental more change.
    [Show full text]
  • Edsger W. Dijkstra: a Commemoration
    Edsger W. Dijkstra: a Commemoration Krzysztof R. Apt1 and Tony Hoare2 (editors) 1 CWI, Amsterdam, The Netherlands and MIMUW, University of Warsaw, Poland 2 Department of Computer Science and Technology, University of Cambridge and Microsoft Research Ltd, Cambridge, UK Abstract This article is a multiauthored portrait of Edsger Wybe Dijkstra that consists of testimo- nials written by several friends, colleagues, and students of his. It provides unique insights into his personality, working style and habits, and his influence on other computer scientists, as a researcher, teacher, and mentor. Contents Preface 3 Tony Hoare 4 Donald Knuth 9 Christian Lengauer 11 K. Mani Chandy 13 Eric C.R. Hehner 15 Mark Scheevel 17 Krzysztof R. Apt 18 arXiv:2104.03392v1 [cs.GL] 7 Apr 2021 Niklaus Wirth 20 Lex Bijlsma 23 Manfred Broy 24 David Gries 26 Ted Herman 28 Alain J. Martin 29 J Strother Moore 31 Vladimir Lifschitz 33 Wim H. Hesselink 34 1 Hamilton Richards 36 Ken Calvert 38 David Naumann 40 David Turner 42 J.R. Rao 44 Jayadev Misra 47 Rajeev Joshi 50 Maarten van Emden 52 Two Tuesday Afternoon Clubs 54 2 Preface Edsger Dijkstra was perhaps the best known, and certainly the most discussed, computer scientist of the seventies and eighties. We both knew Dijkstra |though each of us in different ways| and we both were aware that his influence on computer science was not limited to his pioneering software projects and research articles. He interacted with his colleagues by way of numerous discussions, extensive letter correspondence, and hundreds of so-called EWD reports that he used to send to a select group of researchers.
    [Show full text]
  • Graceful Language Extensions and Interfaces
    Graceful Language Extensions and Interfaces by Michael Homer A thesis submitted to the Victoria University of Wellington in fulfilment of the requirements for the degree of Doctor of Philosophy Victoria University of Wellington 2014 Abstract Grace is a programming language under development aimed at ed- ucation. Grace is object-oriented, imperative, and block-structured, and intended for use in first- and second-year object-oriented programming courses. We present a number of language features we have designed for Grace and implemented in our self-hosted compiler. We describe the design of a pattern-matching system with object-oriented structure and minimal extension to the language. We give a design for an object-based module system, which we use to build dialects, a means of extending and restricting the language available to the programmer, and of implementing domain-specific languages. We show a visual programming interface that melds visual editing (à la Scratch) with textual editing, and that uses our dialect system, and we give the results of a user experiment we performed to evaluate the usability of our interface. ii ii Acknowledgments The author wishes to acknowledge: • James Noble and David Pearce, his supervisors; • Andrew P. Black and Kim B. Bruce, the other designers of Grace; • Timothy Jones, a coauthor on a paper forming part of this thesis and contributor to Minigrace; • Amy Ruskin, Richard Yannow, and Jameson McCowan, coauthors on other papers; • Daniel Gibbs, Jan Larres, Scott Weston, Bart Jacobs, Charlie Paucard, and Alex Sandilands, other contributors to Minigrace; • Gilad Bracha, Matthias Felleisen, and the other (anonymous) review- ers of papers forming part of this thesis; • the participants in his user study; • David Streader, John Grundy, and Laurence Tratt, examiners of the thesis; • and Alexandra Donnison, Amy Chard, Juanri Barnard, Roma Kla- paukh, and Timothy Jones, for providing feedback on drafts of this thesis.
    [Show full text]
  • The Programming Language Concurrent Pascal
    IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-I, No.2, JUNE 1975 199 The Programming Language Concurrent Pascal PER BRINCH HANSEN Abstract-The paper describes a new programming language Disk buffer for structured programming of computer operating systems. It e.lt­ tends the sequential programming language Pascal with concurx:~t programming tools called processes and monitors. Section I eltplains these concepts informally by means of pictures illustrating a hier­ archical design of a simple spooling system. Section II uses the same enmple to introduce the language notation. The main contribu~on of Concurrent Pascal is to extend the monitor concept with an .ex­ Producer process Consumer process plicit hierarchy Of access' rights to shared data structures that can Fig. 1. Process communication. be stated in the program text and checked by a compiler. Index Terms-Abstract data types, access rights, classes, con­ current processes, concurrent programming languages, hierarchical operating systems, monitors, scheduling, structured multiprogram­ ming. Access rights Private data Sequential 1. THE PURPOSE OF CONCURRENT PASCAL program A. Background Fig. 2. Process. INCE 1972 I have been working on a new programming .. language for structured programming of computer S The next picture shows a process component in more operating systems. This language is called Concurrent detail (Fig. 2). Pascal. It extends the sequential programming language A process consists of a private data structure and a Pascal with concurrent programming tools called processes sequential program that can operate on the data. One and monitors [1J-[3]' process cannot operate on the private data of another This is an informal description of Concurrent Pascal.
    [Show full text]
  • A Comparative Analysis of Structured and Object-Oriented Programming Methods
    JASEM ISSN 1119-8362 Full-text Available Online at J. Appl. Sci. Environ. Manage. December, 2008 All rights reserved www.bioline.org.br/ja Vol. 12(4) 41 - 46 A Comparative Analysis of Structured and Object-Oriented Programming Methods ASAGBA, PRINCE OGHENEKARO; OGHENEOVO, EDWARD E. CPN, MNCS. Department of Computer Science, University of Port Harcourt, Port Harcourt, Nigeria. [email protected], [email protected]. 08056023566 ABSTRACT: The concepts of structured and object-oriented programming methods are not relatively new but these approaches are still very much useful and relevant in today’s programming paradigm. In this paper, we distinguish the features of structured programs from that of object oriented programs. Structured programming is a method of organizing and coding programs that can provide easy understanding and modification, whereas object- oriented programming (OOP) consists of a set of objects, which can vary dynamically, and which can execute by acting and reacting to each other, in much the same way that a real-world process proceeds (the interaction of real- world objects). An object-oriented approach makes programs more intuitive to design, faster to develop, more amenable to modifications, and easier to understand. With the traditional, procedural-oriented/structured programming, a program describes a series of steps to be performed (an algorithm). In the object-oriented view of programming, instead of programs consisting of sets of data loosely coupled to many different procedures, object- oriented programs
    [Show full text]
  • The Programmer As a Young Dog
    The Programmer as a Young Dog (1976) This autobiographical sketch describes the beginning of the author’s career at the Danish computer company Regnecentralen from 1963 to 1970. (The title is inspired by James Joyce’s “A Portrait of the Artist as a Young Man” and Dylan Thomas’s “Portrait of the Artist as a Young Dog.”) After three years in Regnecentralen’s compiler group, the author got the chance to design the architecture of the RC 4000 computer. In 1967, he became Head of the Software Development group that designed the RC 4000 multiprogramming system. The article was written in memory of Niels Ivar Bech, the dynamic director of Regnecentralen, who inspired a generation of young Danes to make unique contributions to computing. I came to Regnecentralen in 1963 to work with Peter Naur and Jrn Jensen. The two of them worked so closely together that they hardly needed to say anything to solve a problem. I remember a discussion where Peter was writing something on the blackboard, when Jrn suddenly said “but Peter ...” and immediately was interrupted with the reply “yes, of course, Jrn.” I swear that nothing else was said. It made quite an impression on me, especially since I didn’t even know what the discussion was about in the rst place. After a two-year apprenticeship as a systems programmer, I wanted to travel abroad and work for IBM in Winchester in Southern England. At that time Henning Isaksson was planning to build a process control computer for Haldor Topse, Ltd. Henning had asked Niels Ivar Bech for a systems programmer for quite some time.
    [Show full text]
  • Further Breakthroughs
    1969 1972 1975 1978 1978 The American space agency, Computer Tomography/CT Completely destroyed, the Eleven people, Bill Gates Louise Joy Brown, NASA, launched the first scans made it possible to Cambodian town of Phnom among them (bottom row, the first baby to be spacecraft to land on the directly reconstruct images Penh fell to the guerrilla first on the left), founded the conceived outside its moon, the Apollo 11. of soft tissue on screen. army, the Khmer Rouge. software company mother’s womb,was Microsoft Corporation. born in Oldham General Hospital in England. ¥ separation of concerns: “...a characteristic for all intelligent thinking ...is, _further breakthroughs that one is willing to study in depth an aspect ofone’s subject matter in isolation for the sake of its own consistency, all the time knowing that one In 1969 the Apollo Guidance Computer steers Apollo 11 to the lunar surface. is occupying oneself only with one of the aspects. ...‘the separation of concerns’, which, even if not perfectly possible, is yet the only available In 1970 the U.S. Department of Defense establishes ARPANET with four technique for effective ordering of one’s thoughts, that I know of.” initial nodes; Xerox Palo Alto Research Centre (PARC) opens its doors with ¥ notion of self-stabilizing systems: a system is self-stabilizing if and only if, the mission to create “the architecture of information”; the first compiler regardless of the initial state, the system is guaranteed to find itself in a for the programming language Pascal, designed by Niklaus Wirth, becomes legitimate state after a finite number of moves operational.
    [Show full text]
  • Structured Parallel Programming with Deterministic Patterns
    Structured Parallel Programming with Deterministic Patterns Michael D. McCool, Intel, [email protected] Many-core processors target improved computational performance by making available various forms of architectural parallelism, including but not limited to multiple cores and vector instructions. However, approaches to parallel programming based on targeting these low-level parallel mechanisms directly leads to overly complex, non-portable, and often unscalable and unreliable code. A more structured approach to designing and implementing parallel algorithms is useful to reduce the complexity of developing software for such processors, and is particularly relevant for many-core processors with a large amount of parallelism and multiple parallelism mechanisms. In particular, efficient and reliable parallel programs can be designed around the composition of deterministic algorithmic skeletons, or patterns. While improving the productivity of experts, specific patterns and fused combinations of patterns can also guide relatively inexperienced users to developing efficient algorithm implementations that have good scalability. The approach to parallelism described in this document includes both collective “data-parallel” patterns such as map and reduce as well as structured “task-parallel” patterns such as pipelining and superscalar task graphs. The structured pattern based approach, like data-parallel models, addresses issues of both data access and parallel task distribution in a common framework. Optimization of data access is important for both many-core processors with shared memory systems and accelerators with their own memories not directly attached to the host processor. A catalog of useful structured serial and parallel patterns will be presented. Serial patterns are presented because structured parallel programming can be considered an extension of structured control flow in serial programming.
    [Show full text]
  • Comparative Studies of 10 Programming Languages Within 10 Diverse Criteria Revision 1.0
    Comparative Studies of 10 Programming Languages within 10 Diverse Criteria Revision 1.0 Rana Naim∗ Mohammad Fahim Nizam† Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Sheetal Hanamasagar‡ Jalal Noureddine§ Concordia University Montreal, Concordia University Montreal, Quebec, Canada Quebec, Canada [email protected] [email protected] Marinela Miladinova¶ Concordia University Montreal, Quebec, Canada [email protected] Abstract This is a survey on the programming languages: C++, JavaScript, AspectJ, C#, Haskell, Java, PHP, Scala, Scheme, and BPEL. Our survey work involves a comparative study of these ten programming languages with respect to the following criteria: secure programming practices, web application development, web service composition, OOP-based abstractions, reflection, aspect orientation, functional programming, declarative programming, batch scripting, and UI prototyping. We study these languages in the context of the above mentioned criteria and the level of support they provide for each one of them. Keywords: programming languages, programming paradigms, language features, language design and implementation 1 Introduction Choosing the best language that would satisfy all requirements for the given problem domain can be a difficult task. Some languages are better suited for specific applications than others. In order to select the proper one for the specific problem domain, one has to know what features it provides to support the requirements. Different languages support different paradigms, provide different abstractions, and have different levels of expressive power. Some are better suited to express algorithms and others are targeting the non-technical users. The question is then what is the best tool for a particular problem.
    [Show full text]
  • Part Iii Harnessing Parallelism
    PART III HARNESSING PARALLELISM The primary impetus behind the study of parallel programming, or concurrent programming as some would call it, was the necessity to write operating systems. While the first computers were simple enough to be considered sequential in nature, the advent of faster central processing units and the accompanying discrepancy in speed between the central processor and periph­ eral devices forced the consideration of possible concurrent activity of these mechanisms. The operating system was asked to control concurrent activity, and to control it in such a way that concurrent activity was maximized This desire for concurrent activity resulted in machine features such as the channel and the interrupt-the mechanism by which termination of an I/O activity is signaled The main problem with the interrupt, as far as the operating system designer was concerned, was its inherent unpredictability. Not knowing exactly when an interrupt could occur, the operating system had to be designed to expect an interrupt at any time. With the advent of multiprogramming and interactive, on-line processing, it became clear that the original motivation for parallelism-the control and exploitation of concurrent I/O-was only a special case, and some fundamen­ tal concepts began to emerge for study and use in more general parallel programming situations. Thus emerged the general idea of a set of processes executing concurrently, with the need for synchronization and mutual exclu­ sion (with respect to time) of some of their activities. The past 10-15 years have seen an enormous amount of activity in studying the general problem, a very small part of which is presented here.
    [Show full text]
  • Edsger Wybe Dijkstra
    In Memoriam Edsger Wybe Dijkstra (1930–2002) Contents 0 Early Years 2 1 Mathematical Center, Amsterdam 3 2 Eindhoven University of Technology 6 3 Burroughs Corporation 8 4 Austin and The University of Texas 9 5 Awards and Honors 12 6 Written Works 13 7 Prophet and Sage 14 8 Some Memorable Quotations 16 Edsger Wybe Dijkstra, Professor Emeritus in the Computer Sciences Department at the University of Texas at Austin, died of cancer on 6 August 2002 at his home in Nuenen, the Netherlands. Dijkstra was a towering figure whose scientific contributions permeate major domains of computer science. He was a thinker, scholar, and teacher in renaissance style: working alone or in a close-knit group on problems of long-term importance, writing down his thoughts with exquisite precision, educating students to appreciate the nature of scientific research, and publicly chastising powerful individuals and institutions when he felt scientific integrity was being compromised for economic or political ends. In the words of Professor Sir Tony Hoare, FRS, delivered by him at Dijkstra’s funeral: Edsger is widely recognized as a man who has thought deeply about many deep questions; and among the deepest questions is that of traditional moral philosophy: How is it that a person should live their life? Edsger found his answer to this question early in his life: He decided he would live as an academic scientist, conducting research into a new branch of science, the science of computing. He would lay the foundations that would establish computing as a rigorous scientific discipline; and in his research and in his teaching and in his writing, he would pursue perfection to the exclusion of all other concerns.
    [Show full text]