A PARADIGM SHIFT TO OOP HAS
OCCURRED… IMPLEMENTATION TO FOLLOW
William Mitchell
Information Science Program
Univ. of Arkansas at Little
Rock
Little Rock, AR 72204
wmmitchell@ualr.edu
ABSTRACT
This paper reflects on the discussions concerning
the first year programming sequence that have transpired at the last few
national symposiums in Computer Science Education and at other computer
education conferences in the past two years.
Both paper and birds-of-a-feather sessions suggest that computer science
educators are deep into the transition from the procedural to object approach
as the preferred basis for the design and implementation of software. This transition has become evident in the
introductory textbooks, but it is more evident in the struggles of a faculty
that has grown up with structured programming and now has to overcome that
deeply entrenched mind-set. The author
reflects on the characteristics of this struggle by comparing it to academic
worldview struggles that have been termed “paradigm shifts.” Such struggles have been studied in other
scientific disciplines and the pattern observed there is emphasized in the
author’s interpretation of recent events in computer science education.
INTRODUCTION
The reaction of the computer education community to
the recent rise of Java and object-oriented perspectives has been less than
warm—many faculty have considered it only another fad. Computer educators since the 1980s have
been torn between trying to distinguish computer science from programming and
trying to relate undergraduate computer science to industry practice. In academe almost everyone was comfortable
with the idea that the core of the discipline was algorithms and data
structures, and that we should focus on the core no matter what technologies
came and went. If they saw it, faculty
probably snickered at Larry O’Brien’s opening sentence of his 1996 trade press
editorial: “Java is the most important programming language since Visual
Basic.” [1] Most computer science
faculty do not consider Visual Basic to be a milestone in programming language
development. Most faculty did agree
with David Kay’s 1996 paper “Bandwagons Considered Harmful,..”[2]. Specifically, most faculty through the
1990s were ambivalent about object orientation despite its apparent popularity
in industry. Mark Temte notes that
over 2000 attended OOPSLA’89 but “in spite of this, there does not as yet
appear to be a very broad effort to bring the object-oriented paradigm into the
undergraduate curriculum.”[3] But as
computer applications grow steadily larger and more intricate, the software
industry moves to those techniques and languages that leverage reuse and
optimize the principles of high cohesion and low coupling and therefore support
software development by teams.
The early 1990s were characterized by disarray in
computer education. Multiple
introductory languages were being touted, ETS was making the hard decision to
institute C++ for the AP exam in Computer Science, and Sun and Microsoft both
were pushing new, visual approaches to developing software. Computing was out of the back room and with
the proliferation of personal computers and the emergence of the Internet it
could never be put back there again.
User interfaces now assumed a make-or-break status for a software
product because computing was no longer based on funneling data to mainframes
and returning reports to decision makers.
Distributed computing was the direction of the future and the client-server
model was dominant. Change was constant,
so few thought about paradigms.
Students and employers expected computer science to provide the
graduates who understood the new concepts and many computing programs added one
or more courses directed at them.
Dorothy Mazaitis’ survey of the computer education literature and
Connecticut computer science programs revealed that in the early 90’s objects
were generally isolated in an upper-level elective offering. She concluded “At the heart of the difficulty
is the fact that a new paradigm is being introduced…students are being asked to
make a shift from the traditional design approach, the structured analysis,
functional decomposition method, to a new strategy.”[4]
The ideas of objects were not new. The principle of information hiding was not new. Abstract data types were widely
presented. But the programming
textbooks of the late 1980s and early 1990s had nothing to say about objects. There was no new worldview in the
discipline, only a budding technology advocated by some software developers. Computer Science though the 1990s remained
committed to a top-down functional decomposition strategy for problem solving
that emphasized, by their very visibility, data structures and algorithms.
SHIFTING
PARADIGMS
It is not surprising
that the term ‘paradigm’ surfaces when one discusses OOP. The term was popularized in the 1970’s by
Thomas Kuhn, a historian of science who proposed a theory about how worldviews
changed in scientific disciplines. [5]
In his view, the disciplinary establishment shares a paradigm that is
taught in text books and defines the context in which “normal” science is
conducted. Normal science is concerned
with the incremental elaboration of the disciplinary worldview—filling out the
implications of that view to verify all that it predicts. When scientists encounter facts that cannot
be explained by the present paradigm they work around them—there are always
unexplained phenomena that will perhaps be better understood at a later time. Historically, however, some critical mass
of unexplained phenomena provokes an explanation that requires a different
worldview, and then the proponents of the two different views academically
debate the relative merits of the contrasting viewpoints, usually with the goal
of reconciling them. Kuhn observes
that the process by which anomalies lead to the creation of a new world view is
subtle but relatively sudden: “…we must recognize how very limited in
both scope and precision a paradigm can be at the time of its first
appearance. Paradigms gain their status
because they are more successful than their competitors in solving a few
problems that the group of practitioners has come to recognize as acute. ”
[6] He further emphasizes that because
there can be only one “normal” science, the paradigm shift represents an
intellectual crises point in the
discipline.
“The transition from a paradigm in crises to new one from which a
new tradition of normal science can emerge is far from a cumulation process,
one achieved by an articulation or extension of the old paradigm. Rather it is a reconstruction of the field
from new fundamentals, a reconstruction that changes some of the field’s most
elementary theoretical generalizations as well as many of its paradigm methods
and applications. During the transition
period there will be a large but never complete overlap between the problems
that can be solved by the old and by the new paradigm. But there will also be a dissimilar
difference in the modes of solution.
When the transition is complete, the profession will have changed its
view of the field, its methods, and its goals. [7]
Kuhn identifies five paradigm shifts in Physics and Astronomy in
3000 years. Could it be that Computer
Science is undergoing its first after a mere 30 years? Some might argue that the Structure
Revolution was a paradigm shift, but most would probably agree that the
“revolution” was merely the establishment of a paradigm out of chaos. There was not enough of a discipline before
1968 to cause a crisis in worldviews.
The transition to object orientation might therefore represent the first
challenge to the “normal” science of computing. If this is so, we can anticipate some of Kuhn’s other
observations:
“Scientists, it should
already be clear, never learn concepts, laws, and theories in the abstract and
by themselves. Instead, these
intellectual tools are from the start encountered in a historically and
pedagogically prior unit that displays them with and through their applications. A new theory is always amassed together with
applications to some concrete range of natural phenomena; without them it would
not even be a candidate for acceptance.
After it has been accepted, these same applications or others accompany
the theory into the textbooks from which the future practitioners will learn
his trade. [8]
The textbook is the token of the prevailing paradigm. What is presented in the textbooks and
impressed on the future professionals is the “authorized” version of the
discipline.
“Textbooks, however, being
pedagogic vehicles for the perpetuation of normal science, have to be rewritten
in whole or in part whenever the language, problem-structure, or standards of
normal science change. In short, they
have to be rewritten in the aftermath of each scientific revolution, and, once
rewritten, they inevitably disguise not only the role but the very existence of
the revolutions that produced them.
Unless he has personally experience a revolution in his own lifetime,
the historical sense either of the working scientist or of the lay reader of
textbook literature extends only to the outcome of the most recent revolutions
in the field. [9]
Making an ugly (AND SOMETIMES ACRIMONIOUS) Transition
Throughout the 1990s the story of the introductory
programming instructor has been the same.
Stuart Reges [10] told it once again to the most recent Symposium,
echoing what Perry and Levin [11] experienced in 1992:
“Like many other intro course instructors, I have been asked over the
past four years to switch from Pascal to a more modern, object-oriented
language. First I was asked to switch
to C++ and a year and a half later, I was asked to switch to Java. With all of that switching, I have found it
difficult to become comfortable enough with the new language to discover how
best to teach it to beginners.
“Because of limited time, my first approach was to simply translate all
of my Pascal programs and teach the course the same way I did previously. Some programs translated better than others,
but in general, my wonderful Pascal examples and programming problems lost much
of their luster when translated. I was
teaching the old course in a new syntax, but I knew that I wasn’t teaching
“real” object-oriented programming. As
a result, the benefit of switching to an object-oriented language was mostly
lost.
The transition to the object paradigm has been ugly
because it is driven by a language choice not by an understanding of problem
solving with an object orientation.
The programming faculty owes their first allegiance to teaching students
to solve problems with algorithms.
“Programming, regardless of the paradigm, is about solving problems with
a computer (Wotz [12]).” Having
collected two decades of experience teaching structured programming, computer
science faculty are understandably loath to abandon what has worked. Through the decade of the 1990s resistance
to object-orientation has been based upon defending what was so widely known.
The interchanges between the small number of object proponents and the large number
of ambivalent, procedure-trained faculty were discernable, but, as Kuhn
predicted, hardly distinguishable from a fad.
Fintan Culwin [13] summarized the situation in 1999 in these words:
“The major justification offered for the continued curriculum dominance
of the old paradigm has two related strands.
The first is that the new paradigm is more complex and hence more
difficult than the old paradigm. The
second is that knowledge and experience of the old paradigm is a necessary
prerequisite for working effectively within [the] new paradigm.
‘The first of these justifications is possibly true but the second is
based upon an obvious fallacy. The
people who decide upon the nature, content and focus of undergraduate
curriculum are, in general, of an age where their own professional and
intellectual development mirrors the development of computing over the last
twenty years or so. Hence their
personal perception of how they learned, possibly only parts of, the new
paradigm is one of an evolutionary advance from the old to the new paradigms’
underpinning concepts and practical skills.
Indeed, the transition from Pascal, a teaching
language pushed by Borland to semi-industrial strength, to C and C++, has been
stepping into deep waters. Both the
language and its development environment are more difficult because they were
not designed with students in mind.
Just trying to teach what had been taught before now became more
difficult. Clearly the presentation of
two paradigms at the introductory level was impossible. Decker and Hirshfield’s “The Top 10 Reasons Why Object-Oriented
Programming Can’t be Taught in CS1,” was a clarion cry of frustration at the
1994 Symposium [14] and it echoes into the new millennium. The arguments presented there are valid
and have been replicated with many experiments. Gafarian [15] recently made this report: “Our experience of teaching C++ using three
different strategies supports the belief that CS1 students do not have the
cognitive framework necessary to grasp the concepts underlying object-oriented
programming whether objects early, intermediate, or late.”
The rejection of object-oriented programming in the
first year is not a rejection of the paradigm, but the admission that two
paradigms in one year are too much.
The bulk of programming instructors recognize that the new paradigm must
be learned, but, because it is associated with certain language constructs that
need not be exercised in the first year, many believe a good foundation can be
laid first that will support the transition at a future point in the
curriculum. This view might be
characterized as design with objects but code with procedures. Marion expressed this evolutionary
philosophy last December [16]:
“ The first question to be addressed is: have the goals for the first
course been changed significantly by the challenges that the object-oriented
methodology and the newer technologies have introduced? The answer is: for the most part, no... A
second question is: should there be
more than one design methodology introduced?
The answer is: yes. It is clear
that the computer science community thinks that object-oriented design is of
sufficient power and importance that it ought to have a prominent role in the
first course.
As Kuhn predicted, conservative, “normal” science
tries to work around anomalies and find a way to incorporate them without
changing worldviews. What is evident
at the recent conferences of computer science educators is that OOP poses a
stark choice—the freshman year will either present objects or it won’t—there is
no middle ground. The paradigm shift
means that topics that have for years been considered “advanced” and relegated
to senior courses will now be presented as fundamental ideas to freshmen. Today proponents of objects call for
objects first—anything less is counter productive.
“Object-orientation is not about classes and functions packaged with
data values. It is about polymorphic
run-time dispatch of method calls. The
implication is that object-orientation is not a simple add on to procedural
programming... This fact implies that the conception of the very nature of
computation must change and that design methodologies must change...Teaching
procedural programming first is a serious mistake and will only confuse
students about the nature of objects when they finally take put the topic.
--Joseph Bergin [12]
“The fundamental reason for teaching with objects as early as possible
in the curriculum is that objects provide a more powerful and flexible
encapsulations than are possible with ordinary functions and pure data
structures. --Richard Rasala [12]
“The movement to object-orientation is not simply a departure from a
procedural approach. In the modern
languages that support objects, we are also presented with multiple issues such
as graphics and threads that must be integrated into a coherent whole. --John
Lewis [17]
“The phrase ‘paradigm shift’ has largely been used to describe a
dichotomy between imperative and object oriented styles of development. However the changes in the nature of
software products, and hence of the processes used to produce them, have been
much more extensive. This richer view
of the nature of computing is inherent within the experiences of students
entering higher education and is at variance with the implicit model enshrined
within academic computing curricula. --Fintan Culwin [13]
Just as in the1970’s there were the defenses for
using the GOTO (error handling) the procedural school will emphasize the
indispensability of procedural view points for various problems, implying that
OOP ignores algorithms. Instead, as
Lewis [17] (and Kuhn) observed, the components of the situation are unchanged
but the way of relating them is now different:
“An object-oriented system
design uses terms and notations that a procedural design does not. It defines relationships that are difficult
if not impossible to discuss in a procedural approach. But many of the underlying goals and
concepts are fundamentally the same.
The differences in approach are so real that they cannot be unified; any more that Newton’s and Einstein’s worldviews can be reconciled into a common perspective. Joseph Bergin [12] states it bluntly: “Since the fact of run-time dispatch changes the game fundamentally, object-oriented software is designed in a completely different way. Since it is so different it must be taught early, if it is to be successfully taught at all.”
The disagreement is
clear-cut, but what is significant is that in the past two years more and more computer
science faculty have engaged in the discussion and are becoming converted to
the objects first approach. In 1995
Perry and Levin wrote
“Today, we are in the midst of a major paradigm shift affecting almost
every aspect of computing—from commercial technology to fundamental
theory…Should students learn object-oriented techniques from the start? The answer is yes, even in the earliest
portions of their training. Indeed, we
think that it would be counterproductive to teach standard techniques of
structured programming early in the curriculum and then add in or switch to
object-oriented methodologies in advanced courses…”[11]
At the time this was a lonely claim. Today, like Java, it seems the ONLY
reasonable thing to do.
Capitulating Competently
As a programming instructor I can remember
programming before the GOTO was considered harmful. I believe the story I read in the late 1970s of a programming
manager that decided to evaluate the merits of structured programming and so
took a sample problem and, after studying the dictums of the new approach,
derived and implemented a solution. He
then turned to solve the problem the old way and drew a blank. There seemed to be no other reasonable way
to solve the problem! This is the
essence of a paradigm shift—logic is suddenly perceived to be all on the side
of the new approach. However, history
tells us that conversion is not automatic.
Those invested in the old paradigm often cannot make the
transition. Industry reports that
experienced COBOL programmers do not readily adapt to C++ and Visual
Basic. We try to train our students to
have the flexibility to adapt to changes in languages, changes in
architectures, and changes in tools, but we, like them, are prone to become
comfortable with what we know and to believe that we can be more productive as
experts in the old rather than as novices in a new approach. How, then, does the faculty make the
transition that the students seem to make so easily? I suggest four cascading guidelines.
I.
We must recognize that our
students have no commitment to any problem-solving methodology. We are the ones who seek to cajole them from ad hoc approaches
and inventive hacks and persuade them of the advantages of coding discipline
and a systematic design and development process. We are successful to the extent that our methods prove more
effective (and often we resort to warnings of dire consequences in the future
when our methods show no particular benefits to the task at hand). We have preconceptions about what is
elementary and what is advanced. We
know that recursion is hard for freshman even though Seymour Papert teaches
LOGO to elementary students. We know
that threads and events are sophisticated topics even though our students have
become thoroughly accustomed to their behavior though the exercise of
GUIs. We have so much respect for the
complexity of the engineering of a computer and the layers upon layers of
hardware, firmware, and software that we believe that every student wants to know
every detail of every layer—and needs to learn it from the inside out like we
did! When we teach objects first, the
responsibility of holding two paradigms in tension will rest solely on the
faculty—it will not burden the students.
II.
Our approach to problem solving must be re-examined. We must accept that an object-oriented problem decomposition is
different from a top-down decomposition.
This will be facilitated if we are able to discard our collection of
favorite problems, the ones we have proved to be most effective in illustrating
the procedural approach. It is
unlikely that the same problem can illustrate two radically different
viewpoints equally well, and even so, there is no advantage to making a contrast
between the two approaches for the student to evaluate. I never tried to explain to freshmen why
they should not use a GOTO. Instead I
ignored the statement except for its application to form a loop in a language
that did not provide a suitable variety of looping constructs, and I corrected
students who used it otherwise. The
instructor’s goal is to magnify the power of the object viewpoint when
organizing problems, so we must initially focus on those problems that
decompose naturally into objects.
Building a new collection of illustrative problems is a time-consuming
task, but a necessary one. If a host
of instructors experiment and share their results the faculty will soon pave a
new pathway to programming maturity. I
have found with Reges that the textbooks do not yet present attractive examples
or exercises. Moreover, interesting
LITTLE problems are hard to construct if interaction via a GUI is
expected.
III.
We need to better appreciate the computing experience that students
bring to the freshman year. Although they are ignorant of
a multitude of computing concepts, computers are no longer mysterious devices
that must be explained to them. Many
may have a vague curiosity as to how the machine works, but all students know
that a complete understanding of the hardware and operating system is not
prerequisite to programming applications.
Students readily accept the mediation of high-level languages and a
plethora of “user friendly” tools that insulate them from the dirty details
down below. It is instructors who feel
uneasy about this situation, and it is our duty to convince our students that a
particular set of details is essential to master if they are to become truly
competent programmers. While there
continues to be a wide disagreement as to which details, student expectations
as to the performances they wish to [quickly] achieve are quite uniform. They EXPECT to build applications that
employ GUIs, and they already know that this is not difficult to do, that there
are tools that make it a point and click exercise. No amount of appealing to “foundational concepts” will convince
students that they are making progress learning modern programming technologies
if their exercises do not obviously extrapolate to producing the kind of
applications with which they are already surrounded. The procedural paradigm fit the era of the data center; the
object paradigm fits the era of digital communication and information
sharing. Computationally intensive
problems have not gone away in the new era; they have merely been overwhelmed
by communication applications.
Therefore, difficult or not, programming exercises must rise above the
focus on computation and embrace a focus on interaction. The common argument against early
sophistication in programming examples and exercises is that they are too
complicated for students to truly understand. In truth, the problem is that such programs are too difficult
for the instructor to explain, motivated, as instructors are, to elucidate all
of the details. There are indeed a lot
of details behind the functioning of an applet, but they do not trouble
students. Wolz has made the transition
to teaching objects to freshmen and observes
“During the past few years I have taught CS1 using objects from the
start with Java. I believe I ignited the
passion for good programming in students. They seem to appreciate what objects
are about, even if they can’t yet completely wrap their tongues around them.”
[12] Students can achieve
understanding at many levels and the object paradigm calls for a re-assessment
of what levels are the focus of the first and subsequent courses.
IV.
The paradigm shift to objects first impacts the entire curriculum. The objects first paradigm is not merely an upheaval in the
first-year programming course; it is a new perspective on how students will be
trained to apply computers. Because
the problems will be different, the tools will be different, and the level of
understanding will be different in the student’s first-year experience, the
second year will have to adjust. As
instructors this fact is terrifying and exciting. Many object adherents in the 1990s, ignorant of how scientific
revolutions unfold, argued for a staged integration of object-orientation so as
to make the transition more comfortable.
It appears that history denies us the comfortable path. “Objects first”
calls for reorganization of the components of the programming curriculum and
new priorities and contexts for many other computing topics. Ed Epp of the University of Portland in the
various conference presentations of his Intermediate Java tutorial gives the
following list of contending approaches that have been lumped into the paradigm
shift:
“Objects first vs. Algorithms First
Applet First vs. Application First
GUI vs. Text IO
Object Patterns vs. Data Structures
Non-conventional vs. Traditional coverage
Rate and level—a deeper look
High level first vs. low level first
Syntax in
lecture vs. syntax in lab
TRANSITION
MILESTONES
It is not the learning about objects that is hard,
it is the unlearning of procedural mores that get in the way of the object
perspective that is hard. Fortunately,
instructors bear the brunt of the burden of unlearning, unless, out of
ignorance, they pass it to their students.
How does an instructor know if his or her efforts to move to an object
orientation have been successful? Can
the procedural mindset really be shed?
For most the answer is certainly yes, but only with concentration. It is easy to lapse and it is tempting to
compromise. Reges [10] asserts that
intellectual assent far precedes practice:
“The answer is to introduce objects early, but almost nobody does
so. Even when objects are introduced
early, they tend to be terrible examples of objects. Our paradigm in procedural was input/process/output. Now that we’re programming in Java, we are
creating objects that encapsulate that paradigm.
This suggests that there are some criteria by which the instructor can judge his or her grasp of the paradigm. Lewis points out another one [17]: “Assuming our goal is to introduce object-oriented concepts, a program should never consist of a single class containing multiple methods. Such an example demonstrates procedural abstraction, but no object abstraction.”
Learning a new problem
solving method requires practice. I
feel that I have benefited as an instructor by writing programs of greater
complexity than I could ask my students to attempt and then reflecting what I
learned to the class. [18] Such
problems have no obvious internal organization so I have been able to formulate
several approaches and evaluate them.
The students find it fascinating that anyone would generate more than
one solution. CS2 students could
appreciate Nigel Perry’s paper on the Humble Fraction. [19]
I find that students can
successfully interact with existing programs in several ways. The obvious is the use of pre-defined class
libraries or toolkits [20] that provide services that are otherwise messy to
obtain (for example, input/output services).
But also instructive is the modification of applets that already present
an interesting GUI. I have used a
calculator applet as an interface for a variety of numeric input applications
such as an ATM prototype and had students merely re-label some of the keys and
insert different computations. Viera
Proulx [21] describes a traffic light simulation that she has used in CS2 as a
design illustration and given pieces of to students to complete. Reges also reports on his satisfaction with
giving students incomplete programs that he has designed for them to
finish. He would incorporate the kind
of exercise where students are asked to extend the functionality of some
existing classes immediately in CS1:
“If Get A Life becomes available in Java, I will consider using it as
the first program that I discuss and the first one or two programming
assignments that I give.” [10] These
early excursions into multi-page exercises break the tedium of one and two
class problems that seem to students to lead nowhere.
Still another transition
milestone is when the instructor begins to appreciate what the debates are
within the new paradigm. Culwin [13]
acknowledges that even the objects-first proponents have different priorities:
“Within the object first camp there are already differences in emphasis
concerning the importance of various object concepts. Some curricula initially emphasize the importance of learning to
use pre-supplied object classes, usually in an imperative manner, rather than
the development of classes. Others
emphasize the development of classes but prefer to do this by the construction
of large components placing an initial stress on the importance of
encapsulation. Yet others regard
development by extension as a central concept and place the construction of
hierarchies at the start of the learning process.
Lewis warns, “No matter what your definition of objects
first is, it is likely to be different from that of the person next to you.”
[17]
Conclusion
At a birds-of-a-feather
session last March more than one hundred computer science faculty gathered to
talk about the problems of using Java in the freshman year. The discussion quickly changed to what
needed to be taught in the first programming course. One faculty member shouted, “The rules have changed!” We have to teach interactive, event-driven,
graphical interfaces that put the software user in control of the program. There was no dissent. The argument was made there that the shift
was reality and programming instructors could no longer vacillate or attempt to
ignore it. Action was demanded to begin
the work of fleshing out the new paradigm and learning how to work within
it. The only questions raised concerned
what does this mean for the introductory course, how can this be this be done
in my course? Most faculty are like Reges, willing to
change and desiring be up-to-date.
They know, however, that the paradigm shift means more than changing
programming languages. They want to
know the rest. They need more insight and they need more
guidance.
We should all be encouraged
by the fact that the problems of teaching introductory programming from the
object perspective are recognized, that a variety of strategies are being
explored, and by the promise that the revolution will quickly produce a flood
of new and better pedagogical aids.
This paper has suggested that the transition to object-orientation
qualifies as a paradigm shift, it has enumerated four fundamental guidelines
that illuminate the consequences of the changed worldview, and it has suggested
some milestones that the author has found useful in marking the progress toward
presenting programming from this new problem solving perspective. After a decade of indecision, it appears
that the computer science faculty have become convinced that object-orientation
is a paradigm with a present mandate.