TITLE: A Few Thoughts on My Compilers Course
AUTHOR: Eugene Wallingford
DATE: September 25, 2017 3:01 PM
I've been meaning to blog about my compilers course for more
than a month, but life -- including my compilers course --
have kept me busy. Here are three quick notes to prime the
In her post, Kuper said that her first compiler course was "a
lot of hard work" but "the most fun I'd ever had writing code".
I always tell my students that this course will be just like
that for them. They are more likely to believe the first claim
than the second. Diving in, I'm remembering those feelings
firsthand. I think my students will be glad that I dove in.
I'm reliving some of the challenges of doing everything that
I ask them to do. This is already generating a new source of
empathy for my students, which will probably be good for them
come grading time.
- I recently came across Lindsey Kuper's
My First Fifteen Compilers
and thought again about this unusual approach to a
compiler course: one compiler a week, growing last week's
compiler with a new feature or capability, until you have
a complete system. Long, long-time readers of this blog
may remember me
writing about this idea
once over a decade ago.
The approach still intrigues me. Kuper says that it was
"hugely motivating" to have a working compiler at the end
of each week. In the end I always shy away from the
approach because (1) I'm not yet willing to adopt for my
course the Scheme-enabled micro-transformation model for
building a compiler and (2) I haven't figured out how to
make it work for a more traditional compiler.
I'm sure I'll remain intrigued and consider it again in
the future. Your suggestions are welcome!
- Last week, I
mentioned on Twitter
that I was trying to explain how to compute FIRST and
FOLLOW sets using only "plain English". It was hard.
Writing a textual description of the process made me
appreciate the value of using and understanding
mathematical notation. It is so expressive and so
concise. The problem for students is that it is also
quite imposing until they get it. Before then, the
notation can be a roadblock on the way to understanding
something at an intuitive level.
My usual approach in class to FIRST and FOLLOW sets, as
for most topics, is to start with an example, reason
about it in commonsense terms, and only then to formalize.
The commonsense reasoning often helps students understand
the formal expression, thus removing some of its bite.
It's a variant of
the "Concrete, Then Abstract" pattern.
Mathematical definitions such as these can motivate some
students to develop their formal reasoning skills. Many
people prefer to let students develop their "mathematical
maturity" in math courses, but this is really just an
avoidance mechanism. "Let the Math department fail them"
may solve a practical problem, sometimes we CS profs have
to bite the bullet and help our students get better when
they need it.
- I have been trying to write more code for the course this
semester, both for my enjoyment (and sanity) and for use
in class. Earlier, I wrote a couple of toy programs such
a Fizzbuzz compiler.
This weekend I took a deeper dive and began to implement my
students' compiler project in full detail. It was a lot of
fun to be deep in the mire of a real program again. I have
already learned and re-learned a few things about Python,
git, and bash, and I'm only a quarter of the way in! Now
I just have to make time to do the rest as the semester