TITLE: Lessons from Compilers Course Experiment
AUTHOR: Eugene Wallingford
DATE: May 12, 2009 11:27 AM
DESC: 
-----
BODY:
Though final grades are not all yet submitted,
the semester is over.  We made
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2009-04.html#e2009-04-17T20_20_11.htm">
   adjustments to the specification</A>
in my compilers course, and the students were
able to produce a compiler that produced compilable,
executable Java code for a variety of source
programs.  For the most part, the issues we
discussed most at their finals week demo dealt
with quality control.  We found some programs
that confounded their parser or code generator,
which were evidence of bits of complexity they
had not yet mastered.  There is a lesson to be
learned: theory and testing often take a back
seat to team dynamics and practices.  Given the
complexity of their source language, I was not
too disappointed with their software, though I
think this team fell short of its promise.  I
have been part of teams that have fallen similarly
short and so can empathize.

So, what is the verdict on a couple of
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2009-01.html#e2009-01-07T18_18_57.htm">
   new ideas we tried this semester</A>:
letting the team design its own source language
and working in a large team, of six?  After their
demo, we debriefed the project as a group, and
then I asked them to evaluate the project and
course in writing.  So I have some student data
on which to draw as well as my own thoughts.

On designing their own language: <EM>yes, but</EM>.
Most everyone enjoyed that part of the project,
and for some it was their favorite activity.
But the students found themselves still churning
on syntax and semantics relatively late into the
project, which affected the quality and stability
of their parser.  We left open the possibility of
small changes to the grammar as they learned more
about the language by implementing it, but this
element of reality complicated their jobs.  I did
not lock down the language soon enough and left
them making decisions too late in the process.

One thing I can do the next time we try this is
to put a firmer deadline on language design.
One thing thing that the students and I both
found helpful was writing programs in the proposed
language and discussing syntactic and semantic
language issues grounded in real code.  I think
I'll build a session or two of this into the
course early, before the drop-dead date for the
grammar, so that we can all learn as much as we
can about the language before we proceed on to
implementing it.

We also discussed the idea of developing the
compiler in a more agile way, implementing
beginning-to-end programs for increasing subsets
of the language features until we are done.
This may well help us get better feedback about
language design earlier, but I'm not sure that
it addresses the big risks inherent in letting
the students design their own language.  I'll
have to think more on this.

On working is a team of size six: <EM>no</EM>.
The team members and I were unanimous that a
team of size six created more problems than it
solved.  My original thinking was that a larger
team would be better equipped to do the extra
work introduced by designing their own language,
which almost necessarily delayed the start of
the compiler implementation.  But I think we
were bitten by a preemptive variation of
<A HREF="http://en.wikipedia.org/wiki/Brooks'_law">
   Brooks's Law</A>
-- more manpower slowed them down.  Communication
overhead goes up pretty quickly when you move
from a team of three to a team of six, and it
was much harder for the team to handle all of
its members' ideas effectively.  This might well
be true for a team of experienced developers,
but for a team of undergrads working on their
first collaborative project of this scale, it
was an occasional show-stopper.  I'll know
better next time.

As an aside, one feature the students included
in the language they designed was first-class
functions.  This clearly complicated their
syntax and their implementation.  I was pleased
that they took the shot.  Even after the project
was over and they realized just how much extra
work first-class functions turned out to be,
the team was nearly unanimous in saying that,
if they could start over, they would retain
that feature.  I admire their spunk and their
understanding of the programming power this
feature gave to their language.
-----