TITLE: Preparing for Fall Compilers Course (Almost)
AUTHOR: Eugene Wallingford
DATE: July 09, 2007  7:28 PM
DESC: 
-----
BODY:
Summer is more than half over.  I had planned by now to be
deep in planning for my fall compilers course, but the
other work has kept me busy.  I have to admit also to
suffering from a bout of intellectual hooky.  Summer is a
good time for a little of that.

Compilers is a great course, in so many ways.  It is one
of the few courses of an undergraduate's curriculum in
which students live long enough with code that is big
enough
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-05.html#e2007-05-21T16_45_18.htm">
   to come face-to-face with technical debt</A>.
Design matters, implementation matters, efficiency matters.
Refactoring matters.  The course brings together all of
the strands of the curriculum into a real project that
requires knowledge from the metal up to the abstraction of
language.

In the last few weeks I've run across several comments
from professional developers extolling the virtues of
taking a compilers course, and often lamenting that too
many schools no longer require compilers for graduation.
We are one such school; compilers is a project option
competing with several others.  Most of the others are
perceived to be easier, and they probably are.  But few
of the others offer anything close to the sort of capstone
experience that compilers does.

In a comment on this post titled
<A HREF="http://www.25hoursaday.com/weblog/2007/06/27/ThreeThingsILearnedAboutSoftwareInCollege.aspx">
    Three Things I Learned About Software in College</A>,
<A HREF="http://www.robertblum.com/">
   Robert Blum</A>
writes:

<BLOCKQUOTE><EM>
Building OSes and building compilers are the two ends of
the spectrum of applied CS.  Learn about both, and you'll
be able to solve most problems coming your way.
</EM></BLOCKQUOTE>

I agree, but a compilers course can also illuminate theoretical
CS in ways that other courses don't.  Many of the neat ideas
that undergrads learn in an intro theory course show up in the
first half of compilers, where we examine grammars and build
scanners and parsers.

My favorite recent piece on compilers is ultra-cool Steve
Yegge's
<A HREF="http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html">
   Rich Programmer Food</A>.
You have to read this one -- promise me! -- but I will tease
you with Yegge's own precis:

<BLOCKQUOTE><EM>
Gentle, yet insistent executive summary: If you don't know
how compilers work, then you don't know how computers work.
If you're not 100% sure whether you know how compilers work,
then you don't know how they work.
</EM></BLOCKQUOTE>

Yegge's article is long but well worth the read.

As for my particular course, I face many of the same issues
I faced
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2006-01.html#e2006-01-14T15_29_56.htm">
   the last time I taught it</A>:
choosing a good textbook, choosing a good source language,
and deciding whether to use a parser generator for the main
project are three big ones.  If you have any suggestions,
I'd love to
<A HREF="mailto:wallingf@cs.uni.edu">
   hear from you</A>.
I'd like to build a larger, more complete compiler for my
students to have as a reading example, and writing one
would be the most fun I could have getting ready for the
course.

I do think that I'll pay more explicit attention in class
to refactoring and other practical ideas for writing a big
program this semester.  The extreme-agile idea of
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2006-05.html#e2006-05-17T15_10_03.htm">
   15 compilers in 15 days</A>,
or something similar, still holds me in fascination, but at
this point I'm in love more with the idea than with the
execution, because I'm not sure I'm ready to do it well.
And if I can't do it well, I don't want to do it at all.
This course is too valuable -- and too much fun -- to
risk on an experiment in whose outcome I don't have enough
confidence.

I'm also as <EM>excited</EM> about teaching the course as
the last time I taught it.  On a real project of this
depth and breadth, students have a chance to take what
they have learned to a new level:

<BLOCKQUOTE><EM>
How lasts about five years, but <STRONG>why is forever</STRONG>.
</EM></BLOCKQUOTE>

(I first saw that line in Jeff Atwood's article
<A HREF="http://www.codinghorror.com/blog/archives/000220.html">
   Why Is Forever</A>.
I'm not sure I believe that understanding why is a right-brain
attribute, but I do believe in the spirit of this assertion.)
-----