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 More Concrete Ideas for the course, following up on an entry about extravagant ideas. I even had a geeky Scheme joke to open, asking whether that was ((More Concrete) Ideas) or (More (Concrete Ideas)). 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 an entry on open dialogue 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 epic failures 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,
My usual strategy with all but the most basic of the problems is to stare at them for a while and then walk away.
(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, please let me know! One student tweeted after the course:
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.
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. -----