105

Perspectives on computer science education

N i k l a u s W i r t h

Eidgen6ssische Technische llochschule, 8092 Zurich, Switzerland

Abstract. It is claimed that there should be a difference be- tween education at the university level and that in a trade school. The student at the academic level should receive train- ing in analyzing and abstraction in addition to building. Yet theoretical knowledge must be applied and should lead to clearer and neater designs. Another important goal is to learn to distinguish the essentials from the "bells and whistles,'" genuine needs from toys. The conclusion is that it may be hard to design a reliable and effective system, but it is even harder to design one that others will want to use.

Keywords: computer science education

Niklaus Wirth is Professor of Com- puter Science at the Swiss Federal In- stitute of Technology (ETH) in Zurich. He has developed the programming languages Algol W, Pascal, Modula-2 and, most recently, Oberon. He has been a teacher of computer science since 1963, and he was an early propo- nejat of structured programming on the basis of structured languages. He also designed the workstations Lilith (1979) and Ceres, the latter along with the operating system Oberon.

Education & Computing 7 (1991) 105-109 Elsevier

The question before us is: what can reasonably be expected of a computer science graduate in the future a n d - - f o r that ma t t e r - - a t the present time? I shall venture to suggest a few possible expecta- tions. Assuming--a bold assumption indeed-- agreement on these expectations, we can proceed to ponder the consequences on curricula and methods to achieve them. Do curricula and meth- ods call for changes, or can we proceed with "business as usual"?

My focus is on education in computer science at the academic level. I should like to emphasize at the outset that "computer science" is a standard label. If we take it literally, we are confronted with the need for clarification of our understanding of the term. I a m - - i n time-honoured tradi t ion--used to distinguishing between the exact sciences and engineering disciplines. The sciences are con- cerned with the accumulation of knowledge about facts ("science" coming from the Latin scire, to know). Physics, chemistry, biology, geology and astronomy are the bodies of knowledge about various phenomena of nature. The work of scien- tists in these disciplines consists of the analysis of such phenomena, the postulation of hypotheses and testing the latter in experiments. The en- gineering disciplines are concerned with the accu- mulation of knowledge about methods of building artefacts. The work of engineers consists of the synthesis of parts and methods to construct a device that meets its specifications and fulfils its purpose.

The principal difference between the exact sci- ences and engineering disciplines is their respec- tive emphasis on analysis and synthesis. But they have common aspects as well. Both require ex- actness; both build on profound knowledge of the laws and rules governing the subject. The scientist discovers properties and postulates theories that must withstand tests in nature at any time and place. The engineer must construct machinery that performs according to expectations at any time and place. The scientist must crystallize properties formulated in as general a way as possible, ab- stracting from the complexity with which nature confronts him. The engineer must build his

0167-9287/91/$03.50 © 1991 - Elsevier Science Publishers B.V. All rights reserved

106 N. |Virth / Perspectives on computer science education

artefacts as simply and as economically as possi- ble, even when confronted with complex require- ments. Often he is called on to reduce unnecessary complexity of the given specifications.

From the foregoing, you may gather that I classify what is commonly labelled "computer sci- ence" as an engineering discipline, and that I shall ask of a computer science graduate abilities that are traditionally expected of engineers rather than scientists.

A tradition dating back to the German scientist Alexander von Humboldt put universality before specifics and gave institutions of higher learning the name "university." Emphasis was placed on broad knowledge, on the ability to analyze a situa- tion and to draw conclusions based on logical thinking, on understanding in the broadest sense, on the ability to perceive relations among various desiderata, on knowledge about the nature of things and about the history of their evolution.

This contrasted with training for a specific pro- fession and acquiring special and individual skills. With the advent of engineering disciplines towards the end of the last century, the dilemma arose that the very core of the new disciplines was the acquisition of skills, and for a long time (in fact until the middle of this century), technical schools of higher learning were denied the title "univer- sity."

The first thing we must realize is that the modern university has little in common with Humboldt's ideal. No longer is it a small 61ite that is admitted to the temples of academia; the mod- ern university is the place where everyone capable of enduring an extended education acquires his training. Whether we applaud this fact or not, it has exerted tremendous influence on, and required deep changes in, the nature of academic institu- tions. Nor is the declared mission of universities exclusively the promulgation of knowledge and discovery; with the advent of engineering disci- plines the teaching of know-how and skills inher- ently took its place among the university's objec- tives. The clear distinction between universities and schools oriented towards particular profes- sions (trade schools) diminished, and today the question of whether there is still a difference must often remain unanswered. In any case, the trends are continuing, and Humboldt's model belongs to the past.

Having established the framework, we can pro-

ceed towards specifics. What are the goals of a university education in computer science? What do we expect of its graduates? Let me enumerate a few requirements as I perceive them.

(1) The ability to analyze a problem carefully, to perform a careful search for a solution based on broad knowledge of the subject matter, paired with the courage to reject a chosen path in order to find a more appropriate one, to "shake down," to tune a design until every part of it can be convincingly explained and justified. In short: de- dication.

(2) The ability to distinguish the essential from the detail, what is truly appropriate from what is merely convention, and genuine contributions from concessions to popular fads and standards.

(3) The drive to use resources economically and sparingly, no matter how "cheap" they may have been advertised. Closely coupled with this is the drive to avoid the creation of unnecessary com- plexity. If a program's size can be halved, the chances are good that it will become much easier to demonstrate its correctness convincingly.

(4) A broad knowledge of basic algorithms and system architectures, and of their interplay. The traditional von Neumann architecture is a minimal and therefore the most universal interpreter of sequential instructions. Parallel machines feature architectures which are more complex and inher- ently more specialized. Parts of their programs are frozen in the machine's architecture. In the future, program design and architectural design will have to proceed concurrently with increasing frequency.

(5) The ability to choose the right problems to solve, and to discern pseudo-problems, elevated to worldwide relevance by commercialism and buzz words. Pseudo-problems are tackled because there exist solutions or gadgets for them, and not be- cause they stem from a geniaine need.

The list may well be incomplete, but we shall now proceed to the question of how to achieve these goals, or how to achieve them more effec- tively than in the past. Let me again list a few suggestions.

(1) Provide ample training in analyzing require- ments and in constructing solutions. Require an evaluation of the solution offered, comparison with other, perhaps existing systems, and the search for possibilities of improvement.

(2) Require an untiring critical review and an untiring search for possible simplifications. This

N. tVirth / Perspecti~'es on computer science education 107

search may well start with close scrutiny of the problem's specification. Emphasize that the length of a program is in no way an indicator of its quality, nor of its functionality, not even a meas- ure of the effort invested in its construction.

(3) Pose less ambitious assignments, but in- crease the quality of acceptable solutions.

(4) Ask for.reports about projects, user guides and descriptions and justifications of the given solutions. Insist on concise descriptions and on proper use of language, vocabulary and grammar. Confused design and unclear reasoning invariably reveal themselves in fuzzy expression, inap- propriate terminology and careless phrasing. Even the most sophisticated text processors and laser printers cannot truly conceal shortcomings of con- tent.

(5) Provide adequate, modern tools. These in- clude appropriate--not glorified--workstations, operating systems, programming languages and compilers, and design tools. If necessary, design and implement them yourself. In the selection and design of tools, apply the same criteria as to a student's work. In particular, refrain from unnec- essarily complex tools; instead, choose those which are to the point. I prefer a sparse and reliable tool over one with a large selection of mostly unused bells and whistles. A user manual extending over dozens or even hundreds of pages is an unmis- takable warning that the tool's designers had not completed their work.

You may be disappointed that my modest suggestions do not concern technical details, de- velopments and anticipated trends. You may per- haps have heard these or similar suggestions be- fore, and indeed they are not new. But I believe they are fundamental and time-independent, and herein lies their value. You may also ponder on the effectiveness of these suggestions; sometimes one is driven to doubt the value of teaching a constructive subject in general. Even ignoring the fact that many computer science students lack the aptitude to become good designers, the question of how to convey the proper attitude and skill, the right judgement and critical stance about one's constructions, and a sound programming style, remains unanswered. I merely know from experi- ence that setting the standard through the teacher's own work is a necessary, although perhaps not sufficient, element. After all, how can anyone teach a course about operating systems without at least

attempting to design one, about compilers without having constructed one, or about programming without programming oneself? Yet too many do it. The traditional demand that teaching and research should go hand in hand at universities expresses precisely this concern. Only the teacher's active engagement in the subject--as opposed to his passive engagement through reading textbooks-- provides him with the necessary judgement about a problem's difficulties and pitfalls, and only ac- tive engagement confronts him with the available tools and their pitfalls. The lack of active engage- ment makes him unable to access the student's solutions properly and fairly.

This finally leads me to discuss the rrle of our tools. I have stressed that modern, appropriate tools should be provided. This is in recognition of the fact that tools may increase our capabilities significantly. On the other hand, we can observe an exaggerated emphasis on tools in many places, culminating in many teachers and researchers proudly presenting their equipment rather than their achievements. They have themselves suc- cumbed to the illusion that glorious tools and the ability to handle them suffice to represent an achievement. We should know, however, that tools are merely a means to an end, not the end itself.

Apart from the compiler, the primary tools of a computing engineer are the programming lan- guage and the operating system, nowadays called the "programming environment." Tremendous progress has been made over the last three decades in the design of languages--i.e, of formal nota- t ions - fo r designing complex software. This de- velopment has proceeded in conjuntion with in- sights into the methodology of programming, epi- tomized by terms like "structured programming" and "object-oriented programming," by the con- cept of strong data typing, and "taking into account programming with logical assertions and in- variants. Yet, I submit that these tools should be used sparingly in teaching and in practice, and with great hesitation. I even perceive a retrogres- sive trend towards low-level languages in spite of verbal claims of the high value of abstraction and structured design. How is this deplorable trend to be explained? It must be explained, because other- wise it cannot be reversed, and will result in the continuation of a tremendous waste of intellectual energy.

Alas, I do not really know all the reasons, but I

108 N. IVirth / Perspectives on computer science education

venture to submit a hypothesis. Furthermore, I cling to the meagre hope that merely making people aware of the trend and its consequences may help.

I remember well how Dijkstra reported his nightmares after the announcements of the archi- tecture of the 360 computer, the language PL/1, and the operating system os 360, in the mid-60s. He predicted gloomily that programming would be degraded to learning PL/1 and computer sci- ence to coping with os 360. In the mid-80s, the event recurred: the r61e of PL/1 has been assumed by C, and os 36o has been replaced by tJylx. This time, however, the bandwagon is exceedingly more massive, and the consequences, I am afraid, are more severe and longer lasting. C, designed 20 years ago as an assembler code with the benefit of a phrase-structured syntax, is ill-suited for a struc- tured development of programs. Its compilers can- not support the programmers with such facilities as checking for data type consistency, i.e. checking whether the rules defined for an abstraction have been observed. Its cryptic notatio.n, fraught with pitfalls, resembles that of assemblers and is hardly amenable to logical reasoning. But this is probably its very attraction! Have those who are fascinated by it received proper training in what we believe should be fundamental to computer science edu- cation: exact mathematical reasoning, the drive for economy and clarity?

uNix- - the primary reason for C's popular i ty-- emerged as a sensible alternative to the over- bearingly complex operating systems of its time, primarily MULTICS. In the 20 years of its existence, it has been extended until it has more than over- taken the complexities of its despised ancestors. Having been designed as a small time-sharing system, it has in the meantime become the stan- dard on most single-user workstations with high user interactivity, having been adapted through the repeated addition of layers and subsystems to purposes not envisaged by the designers. In short, it is not a system whose design reflects our stated criteria for good teaching, and it cannot serve as an example of design to be imitated by students.

How can we as teachers cope with the situa- tion? The frequent answer from teachers to my misgivings is that t~r~Ix and C are still the best choices available and are the tools that students will meet in industry. System vendors argue that uNIx and C have become de facto standards in

teaching and therefore offer the best chances for acceptance and profit. The perfect example of a deadlock!

The complacency with which most computing scientists accept this situation is regrettable, and we must conclude that they do not foresee its consequences. It is paradoxical to complain about our difficulties in designing complex software, about its poor quality and high cost, on the one hand, and to promote obsolete tools and practices on the other hand. Conferences on software en- gineering supply ample evidence for the sorry state of the art and the gap between promises and practice.

How, then, can we break this deadlock? How can computer science education contribute to the advancement of our engineering discipline? How can we change the computing field from one where progress primarily stems from the progress made in microelectronics, physics and chemistry, which hide the ineffectiveness of software behind the increased power of processors? How can we achieve progress at the heart of our field: proper design methods? How can we teach our students to work with tools that are themselves fine exam- ples of the methods we teach, and that do not ridicule what we teach and profess? My advice is to create those tools ourselves. After all, our busi- ness is to educate toolsmiths, and hence by design- ing better tools we earn the additional benefit of first-hand practice indispensable for our teaching.

But this is no minor challenge! It requires hard work and earns little reward from academia. And there are handy excuses for shying away from the ordeal; students must be trained to work with tools widely available, we must construct systems capable of cooperation with existing systems, we must not build from scratch and we must not stand on other people's toes, but rather on their shoulders.

I have sympathy for people from industry when they advance this reasoning, because they must translate their work into earnings on a relatively short-term basis. But I have less sympathy when it comes from universities. After all, we are explicitly called on to plan on a longer time scale, and we do not go bankrupt when an idea or an experiment fails. Trying to innovate requires breaking with inadequate old habits, and this is the very chal- lenge of computer science education.

In setting out on the ambitious project to de-

N. IVirth / Perspectit'es on computer science education 109

sign an entire computing system, I had the follow- ing experience. (1) It is relatively easy to write a program for a

well-defined purpose. (2) It is somewhat harder to get the program to

r u n .

(3) It is much harder to demonstrate and prove that the program is correct, i.e. fulfils its pur- pose under all envisaged circumstances.

(4) It is infinitely harder to design a program such that other people desire to use it (without the sometimes fraudulent support of advertisers and marketeers).

(5) Purposes are rarely well-defined, and even if they are, they change and evolve.

Educators in computer science should keep this in mind and direct their efforts accordingly.