Skip to content

TeachScheme Workshop at Brown University

2010 July 20
by Hélène Martin

I’m in Rhode Island for a week-long training on using the TeachScheme curriculum, a set of materials and philosophies for teaching introductory computer science (or is it programming?).  I was able to come all the way out here for one of the free summer workshops through National Science Foundation funding — very cool.  I’ve been hearing about TeachScheme for a while and a couple of teachers in the Seattle area whom I know and love have used some parts of the curriculum to good success.  My interest was sparked by looking over the freely-available textbook (How to Design Programs) and seeing the promise of a structured, deliberate approach to teaching programming.

Almost everything I know about computer science pedagogy I learned through watching Stuart Reges and Marty Stepp teach University of Washington’s CS1 course several times as their teaching assistant.  The course is popular, is more gender-balanced than most CS1 courses, and contributes to attracting high-caliber CS majors.  I don’t think it so much matters that it’s taught in Java, that Stuart uses an overhead projector and Marty uses PowerPoint slides or that jGRASP is the IDE of choice.  What has become clear to me is that the power of the course they have built comes from it being rigorous, deliberately building up complexity, offering lots of opportunities for practice and including a lot of support through TAs and frequent office hours.  Also, both instructors know their material inside and out and value consistency and predictability over the “wow factor.”

I think that this philosophical background meshes nicely with the values of the TeachScheme curriculum (yes, it’s ENTIRELY appropriate to talk about philosophy and values when discussing CS1 courses).  There’s definitely a lot of emphasis on building concepts one by one and increasing the complexity in a calculated, reasonably-paced way.  That may seem obvious, but I’m looking at more and more books and course outlines that feel like a bunch of ‘cool’ things are being thrown together without much regard for cognitive overload.  Several courses seem based on the idea that once a concept is introduced, students can experiment and learn related concepts on their own.  I think the unfortunate side-effect of these poorly-structured courses is that they are particularly discouraging for people without high confidence in their computational abilities — women and minorities.

Our primary instructor for the workshop is Kathi Fisler from WPI.  She knows her material inside and out and values consistency and predictability over the “wow factor!”  She has us meet in the classroom for morning and afternoon lectures followed by lab sessions.  Her lectures involve a lot of code writing on the board and are highly structured — I love it.  Writing code on the board allows Kathi to use color, arrows, annotations, etc and I feel that the students are more engaged because we’re acting as live interpreters.

We’re really being treated as students: Kathi is giving lectures at a faster pace than she would in CS1 but I feel like they’re still pretty close to what students would see.  There’s very little “meta” talk about what she’s doing and we’ve been asked to keep pedagogical questions and concerns for Thursday.  I feel strongly that this is the best way to teach a workshop, probably mostly because I believe in general that teaching is one of those things that’s better taught through apprenticeship rather than in formal classrooms.  Kathi could talk our ears off about effectively using a whiteboard but I think it would really fall flat.  Instead, she’s showing us the way she does it and while it really resonates with me, it may not with others and they’re free to ignore it in favor of other things she’s showing us at the same time.  One teacher/student commented that erasing the white board was taking time which wouldn’t be the case with an interactive white board (a bargain at ~$2,000).  Kathi’s quick response: “it’s valuable reflection time for students.”  Thank you for that.  It’s refreshing to see a highly-effective, low-tech approach to presenting content.

An important piece of the curriculum is the idea of a “design recipe” — a systematic approach to writing functions  that solve particular problems.  It goes something like this (off the top of my head, so I may not use their terms):

  • What’s the data like?  (if there’s a data structure of some sort involved, describe the contents and write examples)
  • What  are the parameter and return types?  What’s a short description of the function?  (write as comments)
  • What are some example calls and what should their results be? (write out test cases to be executed later)
  • Write the body based on templates implied by the data types
  • Run the tests

The idea is that an instructor will refuse to look at a student’s code if he/she doesn’t have comments and test cases.  This piece is fabulous and I certainly intend on emphasizing it more with my students no matter what language I use.

Of course, the early emphasis on data structures points to what really makes this curriculum stand out — it’s based on teaching a functional language.  This is where everyone’s blood pressure goes through the roof.  In CS1, there has been a big debate on whether to teach objects early or later but I don’t think there’s been a terrible lot of noise on whether procedural or object-oriented paradigms are even the right ones to teach.  (Side note: to me, this is really an issue of paradigm and not of language.)

I think there are a lot of very good reasons to teach in a primarily functional paradigm.  Some off the top of my head:

  • Small language core (often true of functional languages, definitely so of Scheme)
  • Don’t need to worry about side effects at first (dealing with data mutation can be entirely mind-boggling)
  • Close analogy with algebra functions
  • Early access to complex data types

I also have a lot of concerns:

  • Functional programming implies certain idioms and ways of thinking about problems.  They’re much less typical than procedural idioms.  This may or may not matter depending on the intended goal of a course.
  • Relatedly, how much transfer is there to other paradigms?  Do students really understand recursion and data structures or do the templates and the syntax trivialize it to the point of preventing students from learning it as a transferable problem-solving technique?
  • Is )))])])) scary?  I don’t think about parens much writing a program but they really boggle my mind when I’m reading code.  This may be a failure on my part, but I’ve found it’s almost easier for me to re-write simple functions than to reason through reading them!  Yikes!
  • As nice as the templates are, I still think it’s very rare for people to naturally think recursively beyond looking at recursive data structures.  Again, do students actually learn recursion in a broad sense?  Does it matter?  I also tend to believe there’s a lot of value to learning iterative constructs.

There definitely is one underlying philosophical point I need to address before being able to figure out how much of a concern these concerns really are — what are the goals of a first programming course?  Is it simply that students have a great experience?  Is it that they build flashy things?  That they be able to get an internship?  I didn’t think that ‘applicability to the real world’ was that important to me but I’ve got 5 students doing technical internships this summer and it’s really rewarding for them.  2 of them have a Java background and are working in C# and 2 of them have a Python background and are working in Perl.  What if they had learned Scheme?

I’m really liking what I’m seeing so far but I’m not ready to become a convert just yet.  That said, there are lots of things I will without doubt adapt and use.  What I may be converted to believing and advocating for is that the functional paradigm is a good way to leverage and expand on students’ algebra knowledge.  Emmanuel Schanzer, whom I mentioned in my CS/IT post, is going to tell us about his middle school outreach program tomorrow.  I’m looking forward to seeing this material again from a slightly more informed perspective.

6 Responses leave one →
  1. Anton Vaynshtok permalink
    July 20, 2010

    “Functional programming implies certain idioms and ways of thinking about problems. They’re much less typical than procedural idioms.”

    Do you have any sources for this? Intuitively I feel that it’s true, but I don’t know if that is only because I (like most programmers of my generation, I think) learned the procedural approach first.

    • Hélène Martin permalink*
      July 23, 2010

      My favorite measure of language popularity is link to Of course it’s not perfect, but I think it gives a pretty good picture. Look at where the functional languages are.

      If most programmers working these days were trained procedurally, chances are that’s what they’ll use, no matter the appropriateness. But what happens when we want to start making things parallel? Stateless (an Android app can be killed and restarted at any point)?

  2. Michael permalink
    August 21, 2010

    “This may be a failure on my part, but I’ve found it’s almost easier for me to re-write simple functions than to reason through reading them!”

    That’s true for most programmers. Most of us would rather tear it all down and build something new than work on something someone else built, because it’s easier, and you don’t have to think as hard. That’s why.

    • Hélène Martin permalink*
      August 21, 2010

      Ahh, yes. As Joel Spolsky says, “It’s harder to read code than to write it.

      But here’s the thing, though. I don’t usually feel this way about my own procedural code! The idea density in functional programming makes it hard for me to unpack even things I’ve just written. Again, it may just be that it’s still a bit of a foreign language to me.

Trackbacks and Pingbacks

  1. Motorcycle Repair and the Art of Overcoming Gender Roles | Hélène Martin
  2. TeachScheme teaches principles. What do the rest of us teach? | Hélène Martin

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS