Interesting Quotations
Edsger W. Dijkstra. “On the Cruelty of Really Teaching Computing Science”, CACM, Vol. 32, No. 12, December 1989, page 1404:
Teaching to unsuspecting youngsters the effective use of formal methods is one of the joys of life because it so extremely rewarding. Within a few months, they find their way into a new world with a justified degree of confidence that is radically novel for them; within a few months, their concept of intellectual culture has acquired a radically new dimension. To my taste and style, that is what education is about.
Geoge Polya. Mathematical Discovery: On Understanding, Learning and Teaching Problem Solving, Wiley, combined edition, 1981, preface:
Solving a problem means finding a way out of a difficulty, a way around an obstacle, attaining an aim which was not immediately attainable. Solving problems is the specific achievement of intelligence, and intelligence is the specific gift of mankind: solving problems can be regarded as the most characteristically human activity. ...
Solving problems is a practical art, like swimming, or skiing, or playing the piano: you learn it only by imitation and practice. ... if you wish to learn swimming you have to go into the water, and if you wish to become a problem solver you have to solve problems.
If you wish to derive the most profit from your effort, look out for such features of a problem at hand as may be useful in handling the problems to come. A solution that you have obtained by your own effort or one that you have read or heard, but have followed with real interest and insight, may become a pattern for you, a model that you can imitate with advantage in solving similar problems. ...
Our knowledge about any subject consists of information and know-how. If you have genuine bona fide experience of mathematical work on any level, elementary or advanced, there will be no doubt in your mind that, in mathematics, know-how is much more important than mere possession of information. ...
What is know-how in mathematics? The ability to solve problems — not merely routine problems but problems requiring some degree of independence, judgment, originality, creativity. Therefore, the first and foremost duty ... in teaching mathematics is to emphasize methodical work in problem solving.
Note: What Polya says for mathematics holds just as much for computing science.
Frederick P. Brooks, Jr., “No Silver Bullet: Essence and Accidents of Software Engineering”, CACM, Vol. 20, No. 4, April 1987, p. 11:
The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under any representation. It is nonetheless highly precise and richly detailed.
I believe the hard part of building software is the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.
If this is true, building software will always be hard. There is inherently no silver bullet.
Edsger W. Dijkstra. “On the Cruelty of Really Teaching Computing Science”, CACM, Vol. 32, No. 12, December 1989, pages 1398-1400:
... computers represent a radical novelty in our history. ... The usual way in which we plan for tomorrow is in yesterday’s vocabulary. ... By means of metaphors and analogies, we try to link the new to the old, the novel to the familiar. ... Coping with radical novelty requires an orthogonal method. ... Coming to grips with a radical novelty amounts to creating and learning a new foreign language that cannot be translated into one’s own mother tongue. ... computers embody not one radical novelty but two of them.
The first radical novelty is a direct consequence of the raw power of today’s computing equipment. ... The programmer is in the unique position that his is the only profession in which such a gigantic ratio
10^9which totally baffles our imagination, has to be bridged by a single technology. He has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before. ...The second radical novelty is that the automatic computer is our first large-scale digital device. ... [A program] has, unavoidably, the uncomfortable property that the smallest possible perturbations — i.e., changes of a single bit — can have the most drastic consequences.
Edsger W. Dijkstra. “On the Cruelty of Really Teaching Computing Science”, CACM, Vol. 32, No. 12, December 1989, page 1401:
What is a program? Several answers are possible. We can view a program as what turns the general-purpose computer into a special-purpose symbol manipulator, and so it does without the need to change a single wire. ... I prefer to describe it the other way around. The program is an abstract symbol manipulator which can be turned into a concrete one by supplying a computer to it. After all, it is the purpose of machines to execute our programs.
So, we have to design abstract symbol manipulators. We all know what they look like. They look like programs or — to use somewhat more general terminology--usually rather elaborate formulae from some formal system. It really helps to view a program as a formula. ... [The programmer] has to derive the formula; he has to derive the program. We know of only one way of doing that, viz., by means of symbol manipulation. And now the circle is closed. We construct our mechanical symbol manipulators by means of human symbol manipulation.
Hence, computing science is--and will always be--concerned with the interplay between mechanized and human symbol manipulation usually referred to as “computing” and “programming,” respectively.
Edsger W. Dijkstra. “On the Cruelty of Really Teaching Computing Science”, CACM, Vol. 32, No. 12, December 1989, pages 1400:
As economics is known as “The Miserable Science,” software engineering should be known as “The Doomed Discipline”: doomed because it cannot even approach its goal since its goal is self-contradictory. ... If you carefully read its literature and analyze what its devotees actually do, you will discover that software engineering has accepted as its charter, “How to program if you cannot.” ... The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsman, viz., programmers.
Edsger W. Dijkstra. “On the Cruelty of Really Teaching Computing Science”, CACM, Vol. 32, No. 12, December 1989, page 1402:
The problem with educational policy is that it is hardly influenced by scientific considerations derived from topics taught and is almost entirely determined by extra-scientific considerations such as the combined expectations of the students, their parents, and their future employers, and the prevailing view of the role of the university is the stress on training its graduates for today’s entry-level jobs ... Do the universities provide for society the intellectual leadership it needs or only the training its asks for? ...
So, if I look into my foggy crystal ball at the future of computing science education, I overwhelmingly see the depressing picture of “business as usual.” The universities will continue to lack the courage to teach hard science; they will continue to misguide the students, and each next stage of the infantilization of the curriculum will be hailed as educational progress.
Terry Winograd. From his response to Dijkstra’s “On the Cruelty of Really Teaching Computing Science”, CACM, Vol. 32, No. 12, December 1989, page 1412-3:
Beyond Dijkstra’s bravado and invective there lurks a coherent argument about the nature of computer science education. Coherent and interesting, but wrong, because it is based on faulty premises. To start out with, Dijkstra is wrong about what computers do, wrong about what programmers do, and wrong about what engineers do. ...
The problem begins with his definition of computers ... In my part of the “real world,” I see computers ... issue payroll checks, control the motions of metalworking machines, format and print architectural drawings and newsletters, and keep my car’s brakes from locking. In doing all this, they may manipulate symbols (and also manipulate electrical and magnetic fields), but that is instrumental--the means to the end.
The second error is his vision of what programmers do ... Dijkstra must face the unpleasant truth that it is the job of someone ... to produce a collection of instructions that allow the computing device to function appropriately in practice. ... once we recognize that we are engaged in the design of operational computing devices, we must train people to think well in operational terms.
The third error is his peculiar view of “software engineering” ... Engineering disciplines are concerned with the construction of devices that can be relied upon to perform a function. The success of such disciplines derives from the fact that past experience can help us avoid future breakdowns. ... There are, indeed, important differences between computing devices and other kinds of devices, for the reasons that Dijkstra points out. On the other hand ... the alleged “radical novelty” of computers is not so earth-shattering as to justify throwing away past experience in order to gain the pristine virtue of the “blank mind.”
From the fact that Dikjstra’s premises are false, it does not logically follow that his conclusions are false ... I fully support his pleas that as educators we demand rigorous thinking, teach the beauty of mathematics, and encourage the virtue of facing uncomfortable truths. But he confuses this with the claim that the essential part of computing education lies in the ability to manipulate formal abstractions, detached from considerations of operational devices, their behaviors, or their embedding in a world of people and activities. If he deludes his students into thinking this, they are in for a rude awakening when they try to function as computing professionals. ... [The] education [of computing professionals] should include a solid grounding in formal methods, but this is just one piece of the preparatory background. To be educated, they need a grounding in the experience of the profession--the examples, methods, and practices. ... Effective learning comes from the experiences of developing the skills they will be employing in their work, with observation and coaching from those who have the expertise.
David Gries. The Science of Programming, Springer-Verlag, 1981, pages 164-5:
The balance between formality and common sense.
Our approach to programming is based on proofs of correctness of programs. But be assured that complete attention to formalism is neither necessary nor desirable. Formality alone is inadequate, because it leads to incomprehensible detail; common sense and intuition alone --the programmer’s main tools till now-- are inadequate, because they allow too many errors and bad designs.
What is needed is a fine balance between the two. Obvious facts should be left implicit, important points should be stressed, and detail should be presented to allow the reader to understand a program as easily as possible. A notation must be found that allows less formalism to be used. Where suitable, definitions in English are okay, but when the going gets rough, more formalism is required. This takes intelligence, taste, knowledge, and practice. It is not easy.
Actually, every mathematician strives for this fine balance. Large gaps will be left in a proof if it is felt that an educated reader will understand how to fill them. The most important and difficult points will receive the most attention. A proof will be organized as a series of lemmas to ease understanding.
This balance between formality and common sense is even more important for the programmer. Programming requires so much more detail, which must be absolutely correct without relying on the goodwill of the reader. In addition, some programs are so large that they cannot be comprehended fully by one person at one time. Thus, there is a continual need to strive for balance, conciseness, and even elegance.
The approach we take, then, can be summarized in the following
- Principle:
- Use theory to provide insight; use common sense and intuition where it is suitable, but fall back upon the formal theory when difficulties and complexities arise.
However, a balance cannot be achieved unless one has both common sense and a facility with theory.
Jacques Cohen. From his response to Dijkstra’s “On the Cruelty of Really Teaching Computing Science”, CACM, Vol. 32, No. 12, December 1989, page 1409:
This response gives me an opportunity to express my own views as an educator in computer science. Our goal should be to provide not one but several approaches in teaching our students how to reason about programs. Dijkstra’s approach is one of them. Among others are the functional and logic programming paradigms. They all share a common denominator: urge the student to have a healthy respect for the craft of programming. By offering a menu of approaches, the student will be better prepared to face whatever “radical novelties” may appear in the future. I also feel that learning the foundations for writing sound programs ought to be fun and there should be a genuine sense of accomplishment when a student runs a program, finds unexpected errors, and corrects them. This, of course, requires inspired, broad-minded teachers ...
Frederick P. Brooks, Jr., “No Silver Bullet: Essence and Accidents of Software Engineering”, CACM, Vol. 20, No. 4, April 1987, p. 18:
The central question in how to improve the software art centers, as it always has, on people.
We can get good designs by following good practices instead of poor ones. Good design practices can be taught. ...
Nevertheless, I do not believe that we can make the next step upward in the same manner. Whereas the difference in poor conceptual designs and good ones may lie in the soundness of the design method, the difference between good designs and great designs surely does not. Great designs come from great designers. Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot inflame or inspire the drudge. ...
I think the most important single effort we can mount is to develop ways to grow great designers ... finding and developing the great designers upon whom the technical excellence of the products will ultimately depend.