ACM Computing Surveys
28A(4), December 1996,
http://www.acm.org/surveys/1996/Formatting/. Copyright ©
1996 by the Association for Computing Machinery, Inc. See the permissions statement below.
Thoughts on Computer Science Education
Department of Computer Science
Bronfman Science Center, Williamstown, MA 01267, USA
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
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
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.
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
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.
We finish with a few more general points.
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.
- 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.
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
Last modified: Tues Oct 1 23:20:43 EDT 1996