TITLE: A Small Curricular Tempest
AUTHOR: Eugene Wallingford
DATE: July 01, 2008 4:21 PM
DESC:
-----
BODY:
A couple of weeks ago I
linked to Shriram Krishnamurthi,
who mentioned a recent SIGPLAN-sponsored workshop that
has proposed a change to ACM's curriculum guidelines.
The change is quite simple, shifting ten hours of
instruction in programming languages from small topics
into a single ten-hour category called "functional
programming". Among the small topics that would be
affected, coverage of recursion and event-driven
programming would be halved, and coverage of virtual
machines and language translation would no longer be
mandated separately, nor would an "overview" of
programming languages.
In practice, the proposal to eliminate coverage of some
areas has less effect than you might think. Recursion
is a natural topic in functional programming, and
event-driven programming is a natural topic on
object-oriented programming. The current recommendation
of three hours total to cover virtual machines and
language translation hardly does them justice anyway;
students can't possibly learn any of the valuable ideas
in depth in that amount of time. If schools adopt this
change, they would be spending the time spent more
productively helping students to understand functional
programming well. Many schools will probably continue
to teach those topics as part of their principles of
programming languages course anyway.
I didn't comment on the proposal in detail earlier
because it seemed more like the shuffling of deck chairs
than a major change in stance. I do approve of the
message the proposal sends, namely that functional
programming is important enough to be a core topic in
computer science. Readers of this blog already know
where I stand on that.
Earlier this week, though, Mark Guzdial blogged
Prediction and Invention: Object-oriented vs. functional,
which has created some discussion in several circles.
He starts with "The goal of any curriculum is to prepare
the students for their future." Here is my take.
Mark seems to be saying that functional programming
is not sufficiently useful to our students to make
it a core programming topic. Mandating that schools
teach ten hours each of functional and object-oriented
programming, he thinks, tells our students that we
faculty believe functional programming is -- or will
be -- as important as object-oriented programming to
their professional careers. Our students get jobs
in companies that primarily use OO languages and
frameworks, and our curricula should reflect that.
This piece has a vocational tone that I find
surprising coming from Mark, and that is perhaps
what most people are reacting to when they read it.
When he speaks of making sure the curriculum teaches
what is "real" to students, or how entry-level
programmers often find themselves modifying existing
code with an OO framework, it's easy to draw a
vocational theme from his article. A lot of
academics, especially computer scientists, are
sensitive to such positions, because the needs of
industry and the perceptions of our students already
exert enough pressure on CS curriculum. In practical
terms, we have to find the right balance between
practical skills for students and the ideas that
underlie those skills and the rest of computing
practice. We already know that, and "esoteric"
topics such as functional programming and computing
theory are already part of that conversation.
Whether Mark is willing to stand behind the vocational
argument or not, I think there is another theme in his
piece that also requires a balance he doesn't promote.
It comes back to the role of curriculum guidelines in
shaping what schools teach and expressing what we
think students should learn. Early on, he says,
I completely disagree that we should try to mandate
that much functional programming through manipulation
of the curriculum standards.
And later:
Then, when teaching more functional programming becomes
a recognized best practice, it will be obvious that it
should be part of the curriculum standards.
The question is whether curriculum standards should be
prescriptive or descriptive.
Mark views the current SIGPLAN proposal as prescribing
an approach that contradicts both current best practice
and the needs of industry, rather describing best
practice in schools around the country. And he thinks
curriculum standards should be descriptive.
I am sensitive to this sort of claim myself, because
-- like Mark! -- I have been contending for many years
with faculty who think OOP is a fad and has no place
in a CS curriculum, or at least in our first-year courses.
These faculty, both at my university and throughout the
country, argue that our courses should be about what
students "really do" in the world, not about esoteric
design patterns and programming techniques. In the
end, these people end up claiming that people like me
are trying to prescribe a paradigm for how our students
should think.
The ironic thing, of course, is that over the last
fifteen years OOP and Java have gone from being something
new to the predominant tools in industry. It's a good
things that some schools started teaching more OOP, even
in the first year, and developing the texts and teaching
materials that other schools could use to join in later.
(The people arguing against OOP in the first year have
not given up the case; they've now shifted to claiming
that we should teach even Java "fundamentals first",
going "back to basics" before diving into all that
complicated stuff about data and procedures bearing
some relation to one another. I've written about
that debate
before and have tremendous respect for many of the
people on the front line of "basics" argument. I
still disagree.)
As in the case of vocational versus theoretical content,
I think we need to find the right balance between
prescriptive and descriptive curriculum standards.
These two dimensions are not wholly independent of
each other, but they are different and so call for
different balances. I agree with Mark that at least
part of our curriculum standard should be descriptive
of current practice, both in universities and in
industry. Standard curricular practice is important in
helping to create some consistency across universities
and helping to keep schools who are out of the know on
a solid and steady path. And the simple fact is that
our students do graduate into professional careers and
need to be prepared to participate in an economy that
increasingly depends on information technology. For
those of us at state-supported universities, this is
a reasonable expectation of the people who pay our
bills.
However, I think that we also need some prescriptive
elements to our curricula. As Alan Kay says in a
comment on Mark's blog, universities have a
responsibility not only to produce graduates capable
in participating in the economy but also to help
students become competent, informed citizens in a
democracy. This is perhaps even more important at
state-supported universities, which serve the citizenry
of the state. This may sound too far from the ground
when talking about computer science curriculum, but
it's not. The same ideas apply -- to growing informed
citizens, and to growing informed technical professionals.
The notion that curriculum standards are partly
prescriptive is not all that strange, because it's not
that different from how curriculum standards have worked
in the past, really. Personally, I like having experts
in areas such as programming languages and operating
systems helping us keep our curricular standards up to
date. I certainly value their input for what they know
to be current in the field. I also value their input
because they know what is coming, what is likely
to have an effect on practice in the near future, and
what might help students understand better the more standard
content we teach.
At first I had a hard time figuring out Mark's position,
because I know him to grok functional programming. Why
was he taking this position? What were his goals? His
first paragraph seems to lay out his goal for the CS
curriculum:
The goal of any curriculum is to prepare the students
for their future. In just a handful of years, teachers
aim to give the students the background to be successful
for several decades.
He then recognizes that "the challenge of creating a
curriculum is the challenge of predicting the future."
These concerns seem to sync quite nicely with the notion
of encouraging that all students learn a modicum about
functional programming! I don't have studies to cite,
but I've often heard and long believed that the more
different programming styles and languages a person
learns, the better a programmer she will be. Mark points
to studies show little direct transfer from skills learned
in one language to skills learned in another, and I do
not doubt their truth. But I'm not even talking about
direct transfer of knowledge from functional programming
to OOP; I'm thinking of the sort of expansion of the
mind that happens when we learn different ways to think
about problems and implement solutions. A lot of the
common OO design patterns borrow ideas from other domains,
including functional programming. How can we borrow
interesting ideas if we don't know about them?
It is right and good that our curriculum standards push
a little beyond current technical and curricular practice,
because then we are able to teach ideas that can help
computing evolve. This evolution is just as important
in the trenches of a web services group at an insurance
company as it is to researchers doing basic science.
In the particular case of functional programming,
students learn not only beautiful ideas but also
powerful ideas, ideas that are germinating now in the
development of programming languages in practice, from
Ruby and Python to .NET. Our students need
those ideas for their careers.
As I mentioned, Alan Kay chimed in with a few ideas.
I think he disagrees that we can't predict the future
by inventing it through curriculum. His idealism on
these issues seems to frustrate some people, but I find
it refreshing. We can set our sights higher and work
to make something better. When I used the allusion to
"shuffling the deck chairs" above, I was thinking of
Kay, who is on record as saying that how we teach CS
is broken. He has also
talked to CS educators
and exhorted us to set our sights higher. Kay supports
the idea of prescriptive curricula for a number of
reasons, the most relevant of which to this conversation
is that we don't want to hard-code accidental or
misguided practice, even if it's the "best" we have
right now. Guzdial rightly points out that we don't
want to prescribe new accidental or misguided practices,
either. That's where the idea of striking a balance
comes in for me. We have to do our best to describe what
is good now and prescribe at least a little of what is
good for the future.
I see no reason that we can't invent good futures by
judiciously defined curriculum, any more than inventing
futures in other arenas. Sure, we face social, societal,
and political pressures, but how many arenas don't?
So, what about the particular
curriculum proposal
under discussion? Unlike Guzdial, I like the message it
sends, that functional programming is an important topic
for all CS grads to learn about. But in end I don't think
it will cause any dramatic changes in how CS departments
work. I used the word "encourage" above rather than
Guzdial's more ominous "mandate", because even ACM's
curriculum standards have no force of law. Under the
proposed plan, maybe a few schools might try to present a
coherent treatment of functional programming where now
they don't, at the expense of covering a few good ideas at
a shallow level. There will continue to be plenty of
diversity, one of the values that guides Guzdial's vision.
On this, he and I agree strongly. Diversity in curricula
is good, both for the vocational reasons he asserts but
also because we learn even better how to teach CS well
from the labors and explorations of others.
-----