TITLE: Thinking about Next Semester's Course Already
AUTHOR: Eugene Wallingford
DATE: November 14, 2017 3:52 PM
We are deep into fall semester. The three teams in
my compilers course
are making steady progress toward a working compiler, and
I'm getting so excited by that prospect that I've written a
few new programs for them to compile. The latest two work
Yet I've also found myself thinking already quite a bit about
my spring programming languages course.
I have not made significant changes to this course (which
introduces students to Racket, functional programming,
recursive programming over algebraic data types, and a
few principles of programming languages) in several years.
I don't know if I'm headed for a major re-design yet, but
I do know that several new ideas are commingling in my
mind and encouraging me to think about improvements to
The first trigger was reading
How to Switch from the Imperative Mindset,
which approaches learning functional style explicitly as a
matter establishing new habits. My students come to the
course having learned an imperative style in Python, perhaps
with some OO in Java thrown in. Most of them are not yet
100% secure in their programming skills, and the thought of
learning a new style is daunting. They don't come to the
course asking for a new set of habits.
One way to develop a new set of habits is to recognize the
cues that trigger an old habit, learn a new response, and
then rehearse that response until it becomes a new habit.
The How to Switch... post echoes a style that I
have found effective when teaching OOP to programmers with
experience in a procedural language, and I'm thinking about
how to re-tool part of my course to use this style more
explicitly when teaching FP.
My idea right now is something like this. Start with simple
examples from the students' experience processing arrays and
lists of data. Then work through solutions in sequence, such
We can also do this with built-in functions, perhaps to start,
which eliminates the need to write a user-defined function.
In effect, this refactors code that the students are already
comfortable with toward common functional patterns. I can use
the same sequence of steps for mapping, folding, and reducing,
which will reinforce the thinking habits students need to
begin writing FP code from the original cues. I'm only just
beginning to think about this approach, but I'm quite
comfortable using a "refactoring to patterns" style in class.
Going in this direction will help me achieve another goal I
have in mind for next semester: making class sessions more
active. This was triggered by my post-mortem of the last
course offering. Some early parts of the course consist of
too much lecture. I want to get students writing small
bits of code sooner, but with more support for taking small,
Paired this change to what happens in class are changes to
what happens before students come to class. Rather than me
talking about so many things in class, I hope to have
- first, use a loop of the sort with which they are
familiar, the body of which acts on each item in the
- then, move the action into a function, which the loop
calls for each item in the collection
- finally, map the function over the items in the
This change will require me to package my notes differently
and also to create triggers and scaffolding for the students'
experimentation before coming to class. I'm thinking of this
as something like a flipped classroom, but with "watching
videos" replaced by "playing with code".
this blog post
triggered a latent desire to make the course more effective
for all students, wherever they are on the learning curve.
Many students come to the course at roughly same level of
experience and comfort, but a few come in struggling from
their previous courses, and a few come in ready to take on
bigger challenges. Even those broad categories are only
approximate equivalence classes; each student is at a
particular point in the development we hope for them. I'd
like to create experiences that can help students all of
these students learn something valuable for them.
I've only begun to think about the ideas in that post.
Right now, I'm contemplating two of ideas from the section
on getting to know my students better: gathering baseline
data early on that I can use to anchor the course, and
viewing grading as planning. Anything that can turn the
drudgery of grading into a productive part of the course
for me is likely to improve my experience in the
course, and that is likely to improved my students'
I have more questions than answers at this point. That's
part of the fun of re-designing a course. I expect that
things will take better shape over the next six weeks or
so. If you have any suggestions,
or tweet to me at @wallingf.
- students reading clear expositions of the material,
in small units that are followed immediately by
- students doing more experimentation on their own in
Dr. Racket, learning from the experiments and learning
find information about language features as they need