TITLE: Resolved: "Object Early" Has Failed
AUTHOR: Eugene Wallingford
DATE: February 26, 2005 5:39 PM
DESC: Have objects failed us, or have we failed objects? Or is the question premature?
-----
BODY:
The focal event of Day 3 at SIGCSE is the 8:30 AM special
session, a panel titled Resolved: "Object Early" Has
Failed. It captures a sense of unrest rippling
through the SIGCSE community, unrest at the use of Java
in the first year, unrest at the use of OOP in the first
year, unrest at changes that have occurred in CS education
over the last decade or more. Much of this unrest
confounds unhappiness with Java and unhappiness with OOP,
but these are real feelings felt by good instructors.
But there are almost as many people uneasy that, after
five or more years, so few intro courses seem to really
do OOP, or at least do it well. These folks are beginning
to wonder whether objects will ever take a place at the
center of CS education, or if we are destined to teach
Pascal programming forever in the language du jour.
This debate gives people a chance to hear some bright
folks on both sides of the issue share their thoughts
and answer questions from one another and the audience.
The panel is structured as a light debate among four
distinguished CS educators:
- Stuart "17 years after writing my Pascal book,
I'm teaching the same stuff in Java... Now
that's fun" Reges
- Eliot "'Objects first' failed? Not according
to Addison Wesley" Koffman
- Michael Kölling, of BlueJ fame
- Kim Bruce, whom you've
read about here earlier
Our fearless leader is Owen "Moderator with a Law"
Astrachan. The fact that the best humor in the
introductions was aimed at the pro-guys may reveal
Owen's bias, or maybe Stuart and Eliot are just
easier targets...
Eliot opened by defining "objects early" as a course
that on using and writing classes before writing control
structures and algorithm development. He made the
analogy to new math: students learn "concepts" but can't
do basic operations well. Most of Eliot's comments
focused on faculty's inability or unwillingness to
change and on the unsuitability of the object-oriented
approach for the programs students write at the CS1
level. The remark about faculty reminded me of a
comment Owen made several years ago in a workshop,
perhaps in an Educators Symposium at OOPSLA, that
our problem here is no longer legacy software but
legacy faculty.
Michael followed quite humorously with a send-up of this
debate as really many debates: objects early, polymorphism
early, interfaces early, GUIs early, events early,
concurrency early... If we teach all of these in Week
1, then teaching CS 1 will be quite nice; Week 2 is the
course wrap-up lecture! The question really is, "What
comes last?" Michael tells us that objects haven't
failed us; we have failed objects. Most of us aren't
doing object yet! And we should start. Michael
closed with a cute little Powerpoint demo showing a
procedural-oriented instructor teaching objects not by
moving toward objects, but by reaching for objects.
When you reach too far without moving, you fall down.
No surprise there!
Stuart returned the debate to the pro side. He
sounded like someone who had broken free of a cult.
He said that, once, he was a true believer. He
drank the kool-aid
and developed a CS 1 course in which students discussed
objects on Day 2. He even presented a popular paper on
the topic at SIGCSE 2000,
Conservatively Radical Java in CS1.
But over time he found that, while his good students
succeeded in his new course, the middle tier of students
struggled with the "object concept". He is willing to
entertain the idea that the problem isn't strictly with
objects-first but with the overhead of OOP in Java, but
pragmatic forces and a herd mentality make Java the
language of choice for most schools these days, so we
need an approach that works in Java. Stuart lamented
that his students weren't getting practice at decomposing
problems into parts or implementing complete programs
on their own. Students seem to derive great pleasure
in writing a complete, if small, program to solve a
problem. This works in the procedural style, where a
50- to 100-line can do something. Stuart asserted that
this doesn't work with an OO style, at least in Java.
Students have to hook their programs in with a large
set of classes, but that necessitates programming to
fixed API. The result just isn't the same kind of
practice students used to get when we taught procedural
programming in,
um, Pascal.
Stuart likens this to learning to paint versus learning
to paint-by-the-numbers. OOP is, to Stuart,
paint-by-the-numbers -- and it is ultimately unsatisfying.
Stuart's contribution to the panel's humorous content was
to claim that the SIGCSE community was grieving the death
of "objects early". Michael, Kim, and their brethren are
in the first stage of grief, denial. Some
objects-early folks are already in the stage of
anger, and they direct their anger at teachers
of computer science, who obviously haven't worked hard
enough to learn OO if they can't succeed at teaching it.
Others have moved onto the stage of bargaining:
if only we form a Java Task Force or construct the right
environment or scaffolding, we can make this work. But
Stuart likened such dickering with the devil to cosmetic
surgery, the sort gone horribly wrong. When you have to
do that much work to make the idea succeed, you aren't
doing cosmetic surgery; you are putting your idea on life
support. A few years ago, Stuart reached the fourth stage
of grief, depression, in which he harbored thoughts
that he was the alone in his doubts, that perhaps he should
just retire from the business. But, hurray!, Stuart finally
reached the stage of acceptance. He decided to go
back to the future
to return to the halcyon days of the 1980s, of simple examples
and simple programming constructs, of control structures
and data structures and algorithm design. At last, Stuart
is free.
Kim closed the position statement portion of the panel
by admitting that it is hard work for instructors who
are new to OO to learn the style, and for others to
build graphics and event-driven libraries to support
instruction. But the work is worth the effort. And
we shouldn't fret about using "non-standard libraries",
because that is how OO programming really works. Stuart
followed up with a question: Graphics seems to be the
killer app of OOP; name two other kinds of examples that
we can use. Kim suggested that the key is not graphics
themselves but the visualization and immediate feedback
they afford, and pointed to
BlueJ
as an environment provides these features to most any
good object.
In his closing statement for the con side, Michael
closed with
quote attributed Planck:
A new scientific truth does not triumph by convincing
its opponents and making them see the light, but rather
because its opponents eventually die, and a new generation
grows up that is familiar with it.
Stuart's closing statement for the pro side was more
serious. It returned to structured programming comparison.
It was hard to make the switch to structured
programming in CS education. Everyone was comfortable
with BASIC; now they had to buy a Pascal compiler for
their machines; a compiler might not exist for the
school's machines; .... But the trajectory of change
was different. It worked, in the sense that
people got it and felt it was an improvement over the
old way -- and it worked faster than the switch to OOP
has worked. Maybe the grieving is premature. Perhaps
objects-early hasn't failed yet -- but it hasn't
succeeded yet, either. According to Stuart,
that should worry us.
The folks on the panel seemed to find common ground
in the idea that objects-early has neither succeeded
nor failed yet. They also seemed to agree that there
are many reasonable ways to teach objects early. And
most everyone seemed to agree that instructors should
use a language that works best for the style of programming
they teach. Maybe Java isn't that language.
In the Q-n-A session that followed, Michael made an
interesting observation: We are now living through
the lasting damage of the decision by many schools to
adopt C++ in CS 1 over a decade ago. When Java came
along, it looked really good as a teaching language
only because we were teaching C++ at the
time. But now we see that it's not good
enough. We need a language suitable for teaching,
in this case, teaching OOP to beginners. (Kim
reminded us of Michael's own Blue language, which
he presented
at the OOPSLA'97 workshop on Resources for Early Object
Design Education.)
I think that this comment shows an astute understanding
of recent CS education history. Back when I first
joined the CS faculty here, I supported the move from
Pascal to C++ in CS 1. I remember some folks at SIGCSE
arguing against C++ as too complex, too unsettled, to
teach to freshmen. I didn't believe that at the time,
and experience ultimately showed that it's really hard
to teach C++ well in CS 1. But the real damage in
everyone doing C++ early wasn't in the doing itself,
because some folks succeeded, and the folks who didn't
like the results could switch to something else. The
real damage was in creating an atmosphere in which
even a complex language such as Java looks good as
a teaching language, an environment in which we seem
compelled by external forces to teach an industrial
language early in our curricula. Perhaps we slid down
a slippery slope.
My favorite question from the crowd came from
Max Hailperin
He asked, "Which of procedural programming and OOP is
more like the thinking we do in computer science when
we aren't programming? The implication is that
the answer to this question may give us a reason for
preferring one over the other for first-year CS, even
make the effort needed to switch approaches a net win
over the course of the CS curriculum. I loved this
question and think it could be the basis of a fun and
interesting panel in its own right. I suspect that,
on Max's implicit criterion, the mathematical and
theoretical sides of computing may make procedural
programming the preferred option. Algorithms and
theory don't seem to have objects in them in the same
way that objects populate an OO program. But what
about databases and graphics and AI and HCI? In these
"applications" objects make for a compelling way to
think about problems and solutions. I'll have to give
this more thought.
After the panel ended,
Robert Duvall
commented that the panel had taught him that the so-called
killer examples workshop
that has taken place at the last few OOPSLAs have failed.
Not that idea -- having instructors share their best
examples for teaching various OO concepts -- is a bad
one. But the implementation has tended to favor glitzy
examples, complicated examples. What we need are
simple examples, that teach an
important idea with the minimum overhead and minimum
distraction to students. I'm certainly not criticizing
these workshops or the folks who organize them, nor
do I think Robert is; they are our friends. But the
workshops have not yet had the effect that we had all
hoped for them.
Another thing that struck about this panel was Stuart's
relative calmness, almost seriousness. He seems at
peace with his "back the '80s" show, and treats this
debate as almost not a joking matter any more. His
demeanor says something about the importance of this
issue to him.
My feeling on all of this was best captured by a cool
graphic that Owen posted sometime near the middle of
the session:
The second attempt to fly Langley's Aerodrome on
December 8, 1903, also ended up in failure. After
this attempt, Langley gave up his attempts to fly
a heavier-than-air aircraft.
(Thanks to the wonders of ubiquitous wireless, I was
able in real time to find Owen's source at
http://www.centennialofflight.gov/.)
I don't begrudge folks like Stuart and Elliott
finding their comfort point with objects later.
They, and more importantly their students, are
best served that way. But I hope that the Michael
Köllings and Kim Bruces and
Joe Bergins
of the world continue to seek the magic of
object-oriented flight for CS 1. It would be
a shame to give up on December 8 with the
solution just around the corner.
-----