TITLE: Looking Ahead -- To Next Week
AUTHOR: Eugene Wallingford
DATE: January 07, 2009  6:18 PM
DESC: 
-----
BODY:
The latest edition of <EM>inroads</EM>, the quarterly
publication of SIGCSE, arrived in my mailbox yesterday.
The invited editorial was timely for me, as I finally
begin to think about teaching this spring.  Alfred Aho,
co-author of the
<A HREF="http://en.wikipedia.org/wiki/Dragon_Book">
   dragon book</A>
and creator of several influential languages and
programming tools, wrote about
<A HREF="http://portal.acm.org/citation.cfm?id=1473195.1473196">
   Teaching the Compilers Course</A>.
He didn't write a theoretical article or a solely
historical one, either; he's been teaching compilers
every semester for the last many years at Columbia.

As always, I enjoyed reading what an observant mind
has to say about his own work.  It's comforting to
know that he and his students face many of the same
challenges with this course as my students and I do,
from the proliferation of powerful, practical tools
to the broad range of languages and target machines
available.  (He also faces a challenge I do not --
teaching his course to 50-100 students every term.
Let's just say that my section this spring offers
ample opportunity for familiarity and one-on-one
interaction!)

Two of Aho's ideas are now germinating in my mind as
I settle on my course.  The first is something that
has long been a feature of my senior project courses
other than compilers: an explicit focus on the
software engineering side of the project.  Back when
I taught our Knowledge-Based Systems course (now
called Intelligent Systems) every year, we paid a
lot of attention to the process of writing a large
program as a team, from gathering requirements and
modeling knowledge to testing and deploying the
final system.  We often used a
<A HREF="http://portal.acm.org/citation.cfm?id=78161">
   supplementary text</A>
on managing the process of building KBS.  Students
produced documents as well as code and evaluated
team members on their contributions and efforts.

When I moved to compilers five or six years ago
after a year on sabbatical, I de-emphasized the
software engineering process.  First of all, I
had smaller classes and so no teams of three, four,
or five.  Instead, I had pairs or even individuals
flying solo.  Managing team interactions became
less important, especially when compared to the
more intellectually daunting content of the compiler
course.  Second, the compiler students tended to
skew a little higher academically, and they seemed
to be able to handle more effectively the challenge
of writing a big program.  Third, maybe I got a
little lazy and threw myself into the fun content
of the course, where my own natural inclinations
lie.

Aho has his students work in teams of five and, in
addition to writing a compiler and demoing at the
end of the semester:
<UL>
<LI> write a white paper on their source language, </LI>
<LI> write a tutorial on using it, and </LI>
<LI> close with a substantial project report written
     by every member of the team.  </LI>
</UL>

This short article has reawakened my interest in
having my students -- many of whom will graduate into
professional careers developing software and managing
its development -- attend more to process.  I'll keep
it light, but these three documents (white paper,
tutorial, and project report) will provide structure
to tasks the students already have to do, such as to
understand their source language well and to explore
the nooks and crannies of its use.

The second idea from Aho's article is to have students
design their own language to compile.  This is something
I have never done.  It is also a feature that brings
more value to the writing of a white paper and a
tutorial for the language.  I've always given students
a language loosely of my own design, adapted from the
many source languages I've encountered in colleagues'
courses and professional experience.  When I design
the language, I have to write specs and clarifications;
I have to code sample programs to demonstrate the
semantics of the language and to test the students'
compilers at the end of the semester.

I like the potential benefits of having students design
their own language.  They will encounter some of the
issues that the designers of the languages they use,
such as Java, C++, and Ada faced.  They can focus their
language in a domain or a technology niche of interest
to them, such as music and gaming or targeting a
multi-core machine.  They may even care more about
their project if they are implementing an engine that
makes their own creation come to life.

If I adopt these course features, they will shift the
burden between instructor and student in some unusual
ways.  Students will have to exert more energy into the
languages of the course and write more documentation.
I will have to learn about their languages and follow
their projects much more intimately as the semester
proceeds in order to be able to provide the right kind
of guidance at the right moments.  But this shift,
while demanding different kinds of work on both our
parts, should benefit both of us.  When I design more
of the course upfront, I have greater control over
how the projects proceed.  This gives me a sense of
comfort but deprives the students of experiences with
language design and evolution that will serve them
well in their careers.  The sense of comfort also
deprives me of something: the opportunity to step
into the unknown in real-time and learn.  Besides,
my students often surprise me with what they have
to teach me.

As I said, I'm just now starting to think about my
course in earnest after letting Christmas break be
a break. And I'm starting none to soon -- classes
begin Monday.  Our first session will not be until
Thursday, however, as I'll begin the week at the
<A HREF="http://www.rebootingcomputing.org/">
   Rebooting Computing summit</A>.
This is not the best timing for a workshop, but it
does offer me the prospect of a couple of travel
days away from the office to think more about my
course!
-----