TITLE: New Year, Old Topics
AUTHOR: Eugene Wallingford
DATE: January 03, 2008 3:25 PM
DESC:
-----
BODY:
I have had a more relaxing break than
last year.
With no traveling and only an occasional hour or two in
my office knocking around, not working, my mind has had
a chance to clear out a bit. This is a good way to start
the year.
I've even managed not to do much professional reading
these past two weeks. About all I've read is a stack of
old
MacWorld
magazines. Every time I or my department buys a Mac, I
receive a complimentary 6-month subscription. I like to
read about and try out all sorts of software, and this
magazine is full of links. But I don't take time to read
all of the issues as they roll in, which explains why I
still had a couple of issues from late 2005 in my stack!
(My favorite new app from this expedition is
CocoThumbX.)
New Year's Eve did bring in my mail the latest issue of
inroads,
the periodic bulletin of SIGCSE. Rather than add it to
my stack of things to read, I decided to browse through it
while watching college football on TV. I found a few items
of value to my work. In the first twenty pages or so, I
encountered several short articles that set the stage for
ongoing discussion in the new year of issues that have been
capturing mind share among CS educators for the last year
or so.
(Unfortunately, the latest issue of inroads
is not yet available in the ACM Digital Library, so I'll
have to add later the links to the articles discussed
below.)
First was Bill Manaris's
Dropping CS Enrollments: Or The Emperor's New Clothes,
which claims that the drop in CS enrollments may well be a
result of the switch to C++, Java, and object-oriented
programming in introductory courses. He includes a form of
disclaimer late in his article by saying that his argument
"is about the possibility that there is no absolute best
language/paradigm for CS1". This is now an almost standard
disclaimer in papers about the choice of language and
paradigm for introductory CS courses, perhaps as an attempt
to avoid the contention of the debates that swirl around the
topic. But the heart of Manaris's article is
a claim that what most of us do in CS1 these days is not
good, disclaimer notwithstanding. That's okay; ideas are meant
to be expressed, examined, and evaluated.
Manaris backs his position from an interesting angle: the
use of usability to judge programming
languages. He quotes
one of Jakob Nielsen's papers:
On the Web, usability is a necessary condition for survival.
If a website is difficult to use, people leave.
If the homepage fails to clearly state what a company offers
and what users can do on the site, people leave.
If users get lost on a website, they leave.
If a website's information is hard to read or doesn't answer
users' key questions, they leave. Note a
pattern here? There's no such thing as a user reading a
website manual or otherwise spending much time trying to figure
out an interface. There are plenty of other websites available;
leaving is the first line of defense when users encounter a
difficulty.
Perhaps usability is a necessary condition for CS1 to retain
students? Maybe students approach their courses and majors in
the same way? They certainly have many choices, and if our
first course raises unexpected difficulties, maybe students
will exercise their choices.
Manaris moves quickly from this notion to the idea that we
should consider the usability of the programming language
we adopt for our intro courses. The idea of studying how
novices learn a language and using that knowledge to inform
language design and choice isn't new. The
psychology of programming
folks have been asking these questions for many years, and
Brad Myers's
research group at CMU has published widely in this area. But
Manaris is right that not enough folks take this kind of
research into account when we think about CS1-2. And when
we do discuss the ideas of usability and learnability, we
usually rely on our own biases and interests as "evidence".
Relying more on usability studies of programming languages
would be a good thing. But they need to be real
studies, not just more of the same old "here's why I think my
favorite language (or paradigm) is best..." Unfortunately,
both of the examples Manaris gives in his article are the
sort we see too often in SIGCSE circles: anecdotal reports of
personal experiences, which are unavoidably biased toward one
person's knowledge and preferences. In one, he tells of his
experience coding some task in languages A and B and reports
that he had "9 compiler errors, one semantic error, and one
'headache' error" in A. (Hmm, could A be Java?) But I wonder
if even some of my CS1 students would encounter these same
difficulties; the good ones can be pretty good.
In the other, a single evaluator collects data from his own
experiences solving a simple task in several different
programming environments. I believe in reporting quantitative
results, but quantitative data from one individual's experience
is of limited value. How many introductory CS1 students would
feel the same? Or intro instructors? We are the ones
who usually make claims about languages and paradigms based
almost solely on their experiences and the experiences of
like-minded colleagues. (Guess what? The folks I meet with
at the OOPSLA educators' symposium find OOP to be a great
way to teach CS1. Shocking!)
And we always need to keep in mind the difference between
essential and gratuitous complexity. I am often reminded of
Alan Kay's story about learning to play violin. Of course it's
hard to learn. But the payoff is huge.
To be fair, Manaris is writing an editorial, not a research
paper, so his examples can be taken as hints, not exact
recommendations. When conducting usability studies of
languages, we need to be sure to seek answers to several
different questions. What works best for the general population
of students? What helps the weakest students learn as much of
value as they can? What helps the strongest students come to
see and appreciate -- even love -- the deep ideas and power of
our discipline?
Manaris closes his paper with an interesting claim:
In the minds of our beginning students, the programming
language/paradigm we expose them to in CS1 is
computer science.
A good CS education should help students overcome this limited
mindset as soon as possible, but for students who are living
through an introduction to computing, this limitation is reality.
Most importantly, for students who never go beyond CS1 -- and
this includes students who might have gone on but who have an
unsatisfying experience and leave -- it is a reality that defines
our discipline for much of the rest of the world.
This idea leads nicely into Henry Walker's column,
What Image Do CS1/CS2 Present to Our Students?
a few pages later in the issue. Walker contrasts the excitement
many practitioners and instructors express about computing with
the reality of most introductory courses for our students, which
are often inward-looking and duller than they should be. We
define our discipline for students in the paradigm and language
we teach them, but also in many other ways: in the approach to
programming we model, in the kinds of assignments we give, and
in the kinds of exam questions we ask. We also define it in the
ideas we expose them to. Is computing "just programming"? If
that's all we show students, then for them it may well be. What
ideas do we talk about in class? What activities do we ask
students to do? How much creativity do we allow them?
CS1 can't be and do everything, but it should be
something more than just a programming language
and an arcane set of rules for formatting and commenting code.
Finally, this idea leads naturally into Owen Astrachan's
Head in the Clouds
only two pages later. In the last few years, Owen has become
an evangelist for the position that computing education has
to be grounded in real problems --
not the Towers of Hanoi,
but problems that real people (not computer scientists) solve
in the world as a part of doing their jobs and living their
lives. This is a way to get out of the inward-looking mindset
that dominates many of our intro courses -- by designing them
to look outward at the world of problems just waiting to be
attacked in a computational way.
Owen also has been railing against the level of discourse in
which CS educators partake, the sort of discourse that ask
"What language should I use in CS1?" rather than "How can I
help my students using computing as a tool to solve problems?"
In that sense, he may not have much interest in Manaris's
article, though he may appreciate the fact the article seeks
to put our focus on how the students who take our courses
learn a language, rather than on the language itself.
I think that we should still start from courses designed
in a meaningful context. There is a lot of power in context,
both for course design and for motivation. Besides, working
from a problem-driven focus gives us an interesting opportunity
for evaluating the effects of features such as a language's
usability. Consider Mark Guzdial's
media computation
approach. His team has developed course materials for
complete CS1 courses in two languages, Python and Java (which
are, not coincidentally, two of the languages that Manaris
discusses in his article). These materials have been developed
by the creators of the approach, with equal care and concern
for the success of students using the approach. Python is in
many ways the simpler language, so it will be interesting to
see whether students find one version of the course more
attractive than the other. I have taught
media comp in Java,
as has a colleague, and this semester he will teach it using
Python. While preparing for the semester, he has already
commented on some of the ways in which Python "gets out of
the way" and lets the class get down to the business of
computing with images and sounds sooner. But that is early
anecdote; what will students think and learn?
I hope that 2008 finds the CS education community asking the
right questions and moving toward answers.
-----