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 to come face-to-face with technical debt. 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 Three Things I Learned About Software in College, Robert Blum writes:
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.
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 Rich Programmer Food. You have to read this one -- promise me! -- but I will tease you with Yegge's own precis:
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.
Yegge's article is long but well worth the read. As for my particular course, I face many of the same issues I faced the last time I taught it: 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 hear from you. 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 15 compilers in 15 days, 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 excited 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:
How lasts about five years, but why is forever.
(I first saw that line in Jeff Atwood's article Why Is Forever. I'm not sure I believe that understanding why is a right-brain attribute, but I do believe in the spirit of this assertion.) -----