TITLE: Class Personality and New Ideas
AUTHOR: Eugene Wallingford
DATE: January 23, 2007  8:09 AM
DESC: 
-----
BODY:
<P ALIGN="right"><EM>
   People you've got the power over what we do <BR/>
   You can sit there and wait  <BR/>
   Or you can pull us through  <BR/>
   Come along, sing the song   <BR/>
   You know you can't go wrong <BR/> <BR/>
   -- Jackson Browne, "The Load-Out"</EM>
   </P>

Every group of students is unique.  This is evident every time
I teach a course.  I think I notice these differences most when
I teach a course Programming Languages, the course I'm teaching
this semester.

In this course, our students learn to program in a functional
style, using Scheme, and then use their new skills to build small
language interpreters that help them to understand the principles
of programming languages.  Because we ask students to learn a new
programming style and a language very different from any they
know when the enter the course, this course depends more than
most on the class's willingness to change their minds.  This
willingness is really attribute of each of the individuals in the
class, but groups tend to develop a personality that grows out of
the individual personalities which make it up.

The last time I taught this course, I had a group that was eager
to try new ideas.  These folks were game from Day 1 to try
something like functional programming.  Many of them had studied
a language called
<A HREF="http://en.wikipedia.org/wiki/MUMPS">
   Mumps</A>
in another course, which had shown them the power that can be
had in a small language that does one or two things well.
Many of them were Linux hackers who appreciated the power of
Unix and its many little languages.  Scheme immediately appealed
to these students, and they dove right in.  Not all of them ended
up mastering the language or style, but all made a good faith
effort.  The result was an uplifting experience both for them and
for me.  Each class session seemed to have a positive energy that
drove us all forward.

But I recall a semester that went much differently.  That class
of students was very pragmatic, focused on immediate skills and
professional goals.  While that's not always my orientation (I
love many ideas for their own sake, and look for ways to improve
myself by studying them), I no longer fault students who feel
this way.  They usually have good reasons for having developed
such a mindset.  But that mindset usually doesn't make for a very
interesting semester studying techniques for recursive programming,
higher-order procedures, syntactic abstractions, and the like.
Sure, these ideas show up -- increasingly often -- in the languages
that they will use professionally, and we can make all sorts of
connections between the ideas they learn and the skills they will
need writing code in the future.  It's just that without a playful
orientation toward new ideas, a course that reaches beyond the
here-and-now feels irrelevant enough to many students to be seem
an unpleasant burden.

That semester, almost every day was a chore for me.  I could feel
the energy drain from my body as I entered the room each Tuesday
and Thursday and encountered students who were ready to leave
before we started.  Eventually we got through the course, and the
students may even have learned some things that they have since
found useful.  But at the time the course was like a twice-weekly
visit to the dentist to have a tooth pulled.

In neither of these classes was there only the one kind of
student.  The personality of the class was an amalgam, driven by
the more talkative members or by the natural leaders among the
students.  In one class, I would walk into the room and find a
few of them discussing some cool new thing they had tried since
the last time we met; in the other, they would be discussing the
pain of the current assignment, or a topic from some other course
they were enjoying.  These attitudes pervaded the rest of the
students and, at least to some extent, me.  As the instructor, I
do have some influence over the class's emotional state of mind.
If I walk into the room with excitement and energy, my students
will feel that.  But the students can have the same effect.  The
result is a symbiotic process that requires a boost of energy from
both sides every class period.

We are now two weeks into the new semester, and I am trying to get
a feel for my current class.  The vocal element of the class has
been skeptical, asking lots of "why?" questions about functional
programming and Scheme alike.  So far, it hasn't been the negative
sort of skepticism that leads to a negative class, and some of the
discussion so far has had the potential to provoke their curiosity.
As we get deeper into the meat of the course, and students have a
chance to write code and see its magic, we could harness their
skepticism into a healthy desire to learn more.

Over the years, I've learned how better to respond to the sort
of questions students ask at the outset of the semester in this
course.  My goal is to lead the discussion in a way that is at
the same time intellectually challenging and pragmatic.
I learned long ago that appealing only to the students' innate
desire to learn abstract ideas such as continuations doesn't
work for the students in my courses.  In most practical ways,
the course is about what they need to learn, not about what I
want blather on about.  And as much as we academics like papers
such as
<A HREF="http://www.math.chalmers.se/~rjmh/Papers/whyfp.html">
   Why Functional Programming Matters</A>
-- and I do like this paper a lot! -- it is only persuasive to
programmers who are open to being persuaded.

But I've also found that pandering to students by telling them
that the skills they are learning can have an immediate effect
on their professional goals does not work in this sort of course.
Students are smart enough to see that even if Paul Graham got rich
<A HREF="http://www.paulgraham.com/avg.html">
   writing ViaWeb in Lisp</A>,
most of them aren't going to be starting their own companies,
and they are not likely to get a job where Scheme or functional
programming will matter in any direct way.  I could walk into
class each day with a different example of a company that has
done something "in the real world" with Scheme or Haskell, and at
the end of the term most students would have perceived only thirty
isolated and largely irrelevant examples.

This sort of course requires balancing these two sets of forces.
Students want practical ideas, ideas that can change how they do
their work.  But we sell students short when we act as if they
want to learn only practical job skills.  By and large they do
want <EM>ideas</EM>, ideas that can change how they think.  I'm
better at balancing these forces with examples, stories, and
subtle direction of classroom discussion than I was ten or fifteen
years ago, but I don't pretend to be able to predict where we'll
all end up.

Today we begin a week studying Scheme procedures and some of the
features that make functional programming different from what they
are used to, such as first-class procedures, variable arity,
higher-order procedures, and currying.  These are ideas with the
potential to capture the students' imagination -- or to make them
think to themselves, "Huh?"  I'm hopeful that we'll start to build
a positive energy that pulls us forward into a semester of discovery.
I don't imagine that they'll be just like my last class; I do hope
that we can be a class which wants to come together a couple of
times every week until May, exploring something new and wonderful.
-----