Thoughts on Computer Science Education

Kim Bruce

Williams college, Department of Computer Science
Bronfman Science Center, Williamstown, MA 01267, USA
kim@cs.williams.edu, http://www.cs.williams.edu/~kim

Introduction

It is difficult to look back and find a "golden era" of computer science education. Curriculum '68 was widely praised for pointing the way to a discipline of computer science, but the field was still so young that a great deal of progress needed to be made before a solid curriculum could be established. Curriculum '78 was roundly criticized as merely describing the current state of computer science education at large universities, rather than pointing the way to the future. The Curricula '91 report came at an awkward time for the discipline - a time when there were strong doubts about the wisdom of teaching an introductory course which focussed almost entirely on teaching programming. Yet the main proposal for a replacement was a broad-based introductory sequence that had yet to be tried at more than a handful of institutions. As a result, the ensuing report did not recommend a specific curriculum, instead presenting a large number (probably too large a number!) of "knowledge units" which departments were urged to combine into a coherent curriculum. While there were many possible implementations presented in that report, it was not sufficient to provide guidance for departments that needed help, and it caused great frustration for authors and publishers who wished to write texts for a national curriculum. I believe that after a period of experimentation, some curricular directions are now becoming clearer. In the next few paragraphs we explore several of these.

The general report on Strategic Directions in Computer Science Education discussed general issues that need to be addressed in CS Education. In this piece I would like to discuss some important particular issues that I feel need to be addressed in designing more up to date curricula in Computer Science. There is no attempt here to be complete, and no claim is made that these are THE most important issues. Instead they reflect my concerns about the impact of programming languages and paradigms as well as my concerns about the role of theory in computing.

Including the object-oriented paradigm into the curriculum

Perhaps the most obvious change since the Curricula '91 report has been the growing importance of the object-oriented paradigm. While this area has been over-hyped, it is becoming clear that there are important advantages (especially in terms of composition and reuse of code) to this way of viewing problems and organizing code. Unfortunately, the current generation of object-oriented programming languages has had many deficiencies compared with more traditional imperative languages. However, there is great hope that the next generation of object-oriented languages will provide more support for the programmer in writing reliable, easy-to-understand code. For example, the new language Java is one of the first object-oriented languages to recognize the importance of language design in supporting reliability and security in the production of software. Future object-oriented languages will combine these features with a simple conceptual model and safe, yet expressive, type systems in order to simplify the production of truly reusable software components.

Unfortunately, for all of the advantages of the object-oriented paradigm, there are corresponding disadvantages. While a good library for an object-oriented language is much more likely to be useful than a similar library for an imperative language, it is also correspondingly more difficult to design a good library. The designer must not only consider the needs of users of the components, but also those who wish to make incremental changes to the provided classes in order to adapt them to slightly different situations. Similarly it is often hard for those who have first learned a more standard imperative approach to learn the object-oriented way of designing algorithms. Those who have shifted to object-oriented languages often report an "aha" experience after several years using these languages. Object-oriented modelling is more difficult to understand and do and will require extra effort and time for the key ideas to get through.

I believe that the object-oriented approach will need to permeate our curriculum, but fear that it may take more time to get the ideas across than more traditional approaches.

Introductory courses

There have been several problems with the introductory course. Many have advocated the need to move from an introductory sequence which is predominately programming to a more broad-based sequence. On the other hand, experience in teaching broad-based introductory sequences has shown that it is quite difficult to create a broad-based course which retains student interest and is perceived as being of value. Moreover there has been no consensus on what language should be used in introductory courses. Pascal has clearly outlived its usefulness, especially in data structures courses where the lack of support for data abstraction is a tremendous handicap. Some have suggested C as the appropriate language, but its support for abstraction is no better than Pascal, and its syntax and low-level orientation make it more error-prone than Pascal.

As stated above, accumulating evidence suggests that object-oriented languages are likely to be dominant in the future. This has led many to advocate C++ as the introductory language of choice. However most programmers have found C++ to be difficult to master, especially if one wants to adopt a truly object-oriented approach to program design. While languages like Eiffel might be a much better choice, political considerations suggest that it is unlikely to emerge from the pack. Instead the new language Java may provide a useful compromise. It's C-like syntax and support for programming on the world-wide web make it an attractive choice for many, while its relatively simple conceptual model, support for garbage collection, and relatively comprehensive graphics library make it an attractive choice for introductory courses. While Java desperately needs support for parameterized classes, there is every indication that this will come in the near future.

Moreover, object-oriented languages' support for modelling suggests that an introductory sequence can be created which discusses issues of modelling as applied to many different areas of computer science. Students could add features to an emulated computer architecture, experiment with different data structures for indexing data bases, or experiment with different heuristics for AI problems. The object-oriented paradigm should make it easier for the instructor to provide a simulator which can then be added to or modified by students. Thus students can build their programming skills while learning about other areas of computer science via emulators. Moreover, the use of inheritance will require students to read other programmers' code, making it easier for them to write good code themselves. This mix of programming and broader-based approaches may prove to be more successful than either of the alternatives.

The importance of learning multiple programming paradigms

In spite of the focus above on object-oriented languages, it is quite important for students to learn other ways of approaching and solving problems. Too many students only know one way to approach problems. All students should be exposed to the functional and perhaps the logic or constraint-based approaches to problem-solving. Those who know only one approach to problem-solving find it quite difficult to shift to a new approach.

The role of theory in CS curricula

Theory has been ghettoized in most current computer-science curricula. It is typically relegated to a single theory of computation course, which is not even required in most programs. Moreover, the material covered in this course has barely changed in the last 20 years, generally representing theory for building compilers and classical material on decidability and complexity classes. Theoretical results play an important role in such areas as data base and the design and semantics of programming languages, but these are rarely mentioned in undergraduate courses. In many colleges and universities, mathematical analyses of algorithm complexity and correctness are given short shrift in favor of covering a larger catalog of algorithms. We need to rethink our approach to theory and mathematical foundations of computing throughout the curriculum. We need not embrace mathematics for its own sake, but instead think of the ways in which it would further students' abilities to deal with a rapidly changing discipline.

Miscellaneous points

We finish with a few more general points.

Too few schools have integrated curricula which ensure that important ideas from earlier courses are built on and expanded from earlier courses. A curriculum should not simply by a collection of courses whose union covers everything that we think an "educated" graduate should know. Key "recurring principles" (for example as described in Curricula '91) should be identified and reinforced throughout a student's academic career. These principles can provide a framework for students to organize both their current knowledge and provide a mechanism to support the acquisition and use of new material.
In most schools, the demands of industry play in important role in curriculum design. Most employers have lists of items they want new graduates to know or to be able to master in order to be hired. A curriculum which turns out students who are not employable will not survive long.
However, colleges and universities need also to think about their graduates long-term needs. If a curriculum is designed around today's industrial needs, what happens to the students when those needs change? Moreover some faculty seem to feel that if most entry level positions require competence of language X on architecture Y with operating system Z, then this means that students should learn these items from the beginning of their academic careers. Others have argued that this is analogous to requiring pilot trainees to begin learning to fly on jumbo jets. As faculty our job is to ensure that students have mastered certain ideas and skills by the end of their academic careers. Starting with simpler ideas and tools allows students to master the fundamentals before attempting to deal with more complex situations and tools. We need to ensure that our students have the ability to keep up with the inevitable changes to the field throughout their careers, as well as have the necessary skills to find productive employment upon graduation. Because of the difficulty of forecasting exactly what those skills are, we should be conservative about chasing after the latest technology, while actively pursuing breakthroughs which have an impact on fundamental principles underlying the discipline.

Several years ago I served on a committee writing a report on teaching computer science. Because the words "Dynamic And Rapidly Changing" were repeated over and over in the report, we coined the acronym DARC in order to save words by describing Computer Science as a "DARC" discipline. The description is still apt as both the focus and many of the details of the discipline change rapidly over time. The difficulty is to be able to stand back far enough and yet still look carefully enough to see the broad outlines of the fundamental principles that graduates need to know. It is easy to fall into the trap of believing all graduates need to know nearly everything. Instead we need to focus on those items which are necessary as a foundation to enable the later mastery of more specialized material. Reasonable people will disagree on what those items are, but we are all likely to learn as we engage in these discussions.

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or permissions@acm.org.

Last modified: Tues Oct 1 23:20:43 EDT 1996

Kim Bruce <kim@cs.williams.edu>