TITLE: Object-Oriented Algorithm Flashback
AUTHOR: Eugene Wallingford
DATE: July 10, 2008 1:54 PM
DESC:
-----
BODY:
Most papers presented at SIGCSE and the OOPSLA Educators'
Symposium are about teaching methods, not computational
methods. When the papers do contain new technical content,
it's usually content that isn't really new, just new to
the audience or to mainstream use in the classroom.
The most prominent example of the latter that comes to
mind immediately is the series of papers by
Zung Nguyen
and
Stephen Wong
at SIGCSE on design patterns for data structures. Those
papers were valuable in principle because they showed
that how one conceives of containers changes when one is
working with objects. In practice, they sometimes missed
their mark because they were so complex that many teachers
in the audience said, "Cool! But I can't do that in class."
However, the OOPSLA Educators' Symposium this year received
a submission with a cool object-oriented implementation
of a common introductory programming topic. Unfortunately,
it may not have made the cut for inclusion based on some
technical concerns of the committee. Even so, I was so
happy to see this paper and to play with the implementation
a little on the side! It reminded me of one of the first
efforts I saw in a mainstream CS book to show how we think
differently about a problem we all know and love when
working with objects. That was Tim Budd's implementation
of the venerable
eight queens problem
in
An Introduction to Object-Oriented Programming.
Rather than implement the typical procedural algorithm
in an object-oriented language, Budd created a solution
that allowed each queen to solve the problem for herself
by doing some local computation and communicating with
the queen to her right. I remember first studying his
code to understand how it worked and then showing it to
colleagues. Most of them just said, "Huh?" Changing
how we think is hard, especially when we already have a
perfectly satisfactory solution for the problem in mind.
You have to want to get it, and then work until you do.
You can still find Budd's code from the "download area"
link on the textbook's page, though you might find a
more palatable version in the download area for the
book's
second edition.
I just spent a few minutes creating a
Ruby version,
which you are welcome to. It is slightly Ruby-ized but
mostly follows Budd's solution for now. (Note to self:
have fun this weekend refactoring that code!)
Another thing I liked about "An Introduction to
Object-Oriented Programming" was its linguistic ecumenism.
All examples were given in four languages: Object Pascal,
C++, Objective C, and Smalltalk. The reader could learn
OOP without tying it to a single language, and Budd could
point out subtle differences in how the languages worked.
I was already a Smalltalk programmer and used this book
as a way to learn some Objective C, a skill which has
been useful again this decade.
(Budd's second edition was a step forward in one respect,
by adding Java to the roster of languages. But it was
also the beginning of the end. Java soon became so
popular that the next version of his book used Java only.
It was still a good book for its time, but it lost some
of its value when it became monolingual.)
-----