TITLE: Looking Backward: Closing the Book on Fall Semester
AUTHOR: Eugene Wallingford
DATE: January 04, 2012  3:26 PM
DESC: 
-----
BODY:
At Week 2 of my fall programming languages course, I planned
to write an entry called <EM>More Concrete Ideas</EM> for
the course, following up on an entry about
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-08.html#e2011-08-27T09_36_20.htm">
   extravagant ideas</A>.
I even had a geeky Scheme joke to open, asking whether that
was <B><TT>((More Concrete) Ideas)</TT></B> or <B><TT>(More
(Concrete Ideas))</TT></B>.

Suddenly, or so it seemed, we were two-thirds of the way
through the course, and I still hadn't written.  Now we
are three weeks past the end of the course.  Time to debrief.
(At least I'm not waiting to debrief the course until the
next time we offer it, in Spring 2013!)

Due to a recent change in my department's prerequisite
structure, I had a more diverse student population this
semester than I have ever had in Programming Languages.
Their diversity covered multiple dimensions, including the
languages they knew well and the level of experience they
had writing larger programs.  Many did not know OOP or Java
yet, which have long been staples of my reference set.

This led to an interesting phenomenon.  One particular
student was at the low end of background, experience, and
skill set.  In most ways, he was more of a rank beginner
than the usual student in the course.  Over the course of
the semester, he asked me questions unlike any I had been
asked in this course for a long while, if ever.  His
questions caused me to step back and focus on basic elements
of the craft of programming that I have never discussed in
the context of this course and functional programming.  At
times it was frustrating, but most of the time it was a
good challenge.

More importantly, his questions exposed for me the sort of
difficulties that I often miss when students are doing
better.  Even students who are doing well in the course
develop subtle misconceptions about the material, or start
with misconceptions that my teaching does address.  However,
their decent scores on quizzes and their general understanding
of the material allow me to gloss over misconceptions that
come back to trouble us later.

This is the frame of mind I was in when I wrote
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-12.html#e2011-12-12T16_43_16.htm">
   an entry on open dialogue</A>
a few weeks back.  Even with my beginner-like student, I did
not enough questions soon enough.  For all I know, students
in previous semesters have had similar problems that I never
addressed in class.  After this round, I am thinking more
concretely about where I have gone wrong and how I might do
better in the future.

As mentioned earlier, I offered students a chance to document
some of their
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-09.html#e2011-09-27T20_08_39.htm">
   epic failures</A>
during the semester.  Of course, students always have that
opportunity; this time, I offered extra credit as an
inducement to take on the challenge.

In the end, roughly a third of the students submitted essays,
though all came in very late in the semester, enough so that
anything I might fold back into the course will have to wait
until the next time around.

I enjoyed several of the essays.  One student learned one
valuable lesson this semester:  "There are only so many hours
in a day."  Another student  wrote,

<BLOCKQUOTE><EM>
My usual strategy with all but the most basic of the
problems is to stare at them for a while and then walk
away.
</EM></BLOCKQUOTE>

(A former student wondered, "But does he ever come back?")

Like many programmers, this student lets his brain work on
a problem over time and eventually arrives at a solution
without the stress of staring at the problem until he gets
it right the first time.  However, he found this semester
that even this approach cannot alleviate all stress, because
sometimes no answer seems to work.  What then?

I'll try the Epic Fail idea again in coming semesters.  I'll
probably give students a bit more guidance about the kind of
failures I mean (not run-of-the-mill stuff, really) and the
kind of write-up that I'm looking for.  As always, students
appreciate examples!

In that vein, I had thought this semester that I would provide
students with occasional example programs (1) to illustrate
functional programming and Scheme outside the realm of the
study of programming languages and (2) to illustrate programming
language topics with non-FP code.  The idea was to broaden the
reach of the course, to help students struggling with FP and
to open doors for those students who were really interested
and ready to see more.

Unfortunately, I did not do nearly enough of this.  Next time,
I will find a way, somehow.  Among the topics that can benefit
most from this idea are continuation-based web servers and
MapReduce.

As I graded the final exam, I was most disappointed with
student understanding of curried functions and of the
equivalence between local variables and function application.
Currying is such a beautiful idea at the heart of functional
style, which we saw repeatedly throughout the semester.  The
local variable/function app idea is one we discussed in some
detail at least three times during the semester, in different
contexts, and which I highlighted as "something that will be
on the final".

I'll think long and hard before I teach the course again
about ways to help students understand these ideas better.
If you have any suggestions,
<A HREF="mailto:wallingf@cs.uni.edu">
   please let me know</A>!

One student tweeted after the course:

<BLOCKQUOTE><EM>
I think the larger examples are what helped ideas stick
in my mind.  This class had the most information I've
learned in a class before.  It was a challenge which
was really refreshing.  Gliding through classes put me
into a lull for awhile.
</EM></BLOCKQUOTE>

It's important for me and other teachers to remember just
how heavy some courses can be.  I'm fully aware that this
course is different than any students have taken before
and that it will challenge them in new ways.  I tell them
so on Day 1.  Still, it's good for me to remember just
what this means for students on a day-to-day basis, and
to find ways to help them face the challenge while they
are in the trenches.

All in all, this was a good group of students.  They were
game for a challenging, deep course and gave me a lot of
their time and energy.  I can't ask for much more than
that.  The good news is that they made decent progress
and should be better prepared for some of the challenges
they'll face in their careers.  And a good number of them
are going on to the compilers course.  Great fun will be
had by all.
-----