TITLE: Thinking Back on My Compiler Course This Fall
AUTHOR: Eugene Wallingford
DATE: December 28, 2021  5:31 PM
DESC: 
-----
BODY:
 Well, fall semester really got away from me quickly.  It seems not long
 ago that I wrote of
<a href="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2021-08.html#e2021-08-27T15_30_38.htm">
   launching the course</a>
 with a renewed mindset of "compilers for the masses, not compilers for
 compiler people".  I'm not sure how well that went this time, as many
 students came into the course with less understanding of the underlying
 machine model and assembly language than ever before.  As a result, many
 of them ended up stressing over low-level implementation details while
 shoring up that knowledge than thinking about some of the higher-level
 software engineering ideas.  I spent more time this semester working
 with more teams to help them understand parsing rules, semantic actions,
 and activation records than in anytime I can remember.

 I suspect that the students' programming maturity and state of knowledge
 at the start of the course are in large part a result of experiencing
 the previous two and a half semesters under the damper of the pandemic.
 Some classes were online, others were hybrid, and all were affected by
 mitigation efforts, doubt, and stress.  Students and professors alike
 faced these effects, me included, and while everyone has been doing
 the best they could under the circumstances, sometimes the best we can
 do comes up a little short.

 At the beginning of the course, I wrote about
<a href="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2021-08.html#e2021-08-29T10_19_40.htm">
   a particular uncertainty</a>
 raised by the preceding pandemic semesters: how isolation and the
 interruption of regular life had reduced the chances for students to
 make friends in the major and to build up personal and professional
 connections with their classmates.  I underestimated, I think, the
 effect that the previous year and a half would have on learning outcomes
 in our courses.

 The effect on project teams themselves turned out to be a mixed bag.
 Three of the five teams worked pretty well together, even if one of the
 teammates was unable to contribute equally to the project.  That's
 pretty typical.  Two other teams encountered more serious difficulties
 working together effectively.  Difficulties derailed one project that
 got off to an outstanding start, and the second ended up being a
 one-person show (a very impressive one-person show, in fact).  In
 retrospect, many of these challenges can be traced back to problems some
 students had with content: they found themselves falling farther behind
 their teammates and responded by withdrawing from group work.  The result
 is a bad experience for those still plugging along.

 That's perhaps too many words about the difficulties.  Several teams
 seemed to have pretty typical experiences working one another, even
 though they didn't really know each other before working together.

 The combination of some students struggling with course content and
 some struggling with collaboration led to mixed bag of results.  Two
 teams produced working compilers that handled essentially all language
 features correctly, or nearly so.  That's pretty typical for a five-team
 semester.  One team produced an incomplete system, but one they could be
 proud of after working pretty hard the entire semester.  That's typical,
 too.

 Two teams produced systems without code generators beyond a rudimentary
 run-time system.  That's a bit unusual.  These teams were disappointed
 because they had set much higher goals for themselves.  Many of these
 students were taking heavy course and research loads and, unfortunately,
 all that work eventually overwhelmed them.  I think I felt as bad for
 them as they did, knowing what they might have accomplished with a more
 forgiving schedule.  I do hope they found some value in the course and
 will be able to look back on the experience as worthwhile.  They learned
 a lot about working on a big project, and perhaps about themselves.

 What about me?  A few weeks into the course, I declared that I was
<a href="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2021-09.html#e2021-09-27T14_04_59.htm">
   programming like a student again</a>,
 trying to implement the full compiler project I set before my students.
 Like many of my students, I accomplished some of my goals and fell
 short when outside obstacles got in the way.  One the front end, my
 scanner is in great shape, while my parser is correct but in need of
 some refactoring.  At that point in the semester, I got busy both with
 department duties and with working one on one with the teams, and my
 productivity dropped off.

 I did implement a solid run-time system, one I am rather happy with.  My
 work on it came directly out of answering students' questions about code
 generation and working with them to investigate and debug their programs.
 I'll have more to say about my run-time system in the next post.

 So, my latest compiler course is in the books.  All in all, my students
 and I did about as well as we could under the circumstances.  There is
 still great magic in watching a team's compiler generate an executable,
 then running that executable on an input that produces tens of thousands
 of activation records and executes several million lines of assembly.
 The best we can do is often quite good enough.
-----