TITLE: More on Problems and Art in Computer Science
AUTHOR: Eugene Wallingford
DATE: July 07, 2008 12:48 PM
DESC:
-----
BODY:
Last week I
wrote about
an essay by Paul Lockhart from a few years ago that
has been making the rounds this year. Lockhart lamented
that math is so poorly misrepresented in our schools
that students grow up missing out on its beauty, and
even still not being able to perform the skills in
whose name we have killed scholastic math. I've long
claimed that we would produce more skilled students
if we allowed them to approach these skills from the
angle of engaging problems. For Lockhart, such
problems come form the minds of students themselves
and may have no connection to the "real world".
In computer science, I think letting students create
their own problems is also quite valuable. It's one
of the reasons that open-ended project courses and
independent undergraduate research so often lead to
an amazing level of learning. When a group of
students wants to train a checkers-playing program
to learn from scratch, they'll figure out ways to do
it. Along the way, they learn a ton -- some of it
material I would have selected for them, some beyond
what I would have guessed.
The problems CS students create for themselves often
do come straight out of their real world, and that's
okay, too. Many of us CS love abstract problems
such as the
why of Y,
but for most of us -- even the academics who make
a living in the abstractions -- came to computing
from concrete problems. I think I was this way,
starting when I learned Basic in high school and
wanted to make things, like crosstables for
chess tournaments and
ratings for the players in our club.
From there, it wasn't that far a journey into
Gödel, Escher, Bach
and grad school! Along the way, I had professors
and friends who introduced me to a world much larger
than the one in which I wrote programs to print pages
on which to record chess games.
This is one reason that I tout Owen Astrachan's
problem-based learning
project for CS. Owen is interested in problems that
come from the real world, outside the minds of the
crazy but harmless computer scientists he and I know,
love, and are. These are the problems that matter
to other people, which is good for the long-term
prospects of our discipline and great for hooking the
minds of kids on the beauty and power of computing.
For computer science students, I am a proponent of
courses built around projects,
because they are big enough to matter to CS students
and big enough to teach them lessons they can't learn
working on smaller pieces of code.
With an orientation toward the ground, discussions of
functional programming versus object-oriented programming
seem almost not to matter. Students can solve any
problem in either style, right? So who cares? Well,
those of us who teach CS care, and our students should,
too, but it's important to remember that this is an
inward-looking discussion that won't mean much to
people outside of CS. It also won't matter much to
our students as they first begin to study computer
science, so we can't turn our first-year courses into
battlegrounds of ideology. We need to be sure that,
whatever style we choose to teach first, we teach it
in a way that helps students solve problems -- and
create the problems that interest them. They style
needs to feel right for the kind of problems we
expose them to, so that the students can begin to
think naturally about computational solutions.
In my department we have for more than a decade
introduced functional programming as a style in our
programming languages course, after students have
seen OOP and procedural programming. I see a lot
of benefit in teaching FP sooner, but that's would
not fit our faculty all that well. (The students
would probably be fine!) Functional programming has
a natural home in our languages course, where we
teach it as an especially handy way of thinking
about how programming languages work. This is a
set of topics we want students to learn anyway, so
we are able to introduce and practice a new style
in the context of essential content, such as how
local variables work and
how to write a parser.
If a few students pick up on some of the beautiful
ideas and go do something crazy, like fire up a
Haskell interpreter and try to grok monads, well,
that's just fine.
-----