COMP 150SVM (Simple Virtual Machines)
Syllabus

(This syllabus is also available in PDF.)

Introduction and welcome

How does one implement a scripting language like, say, Python? The best simple method is to translate the high-level language through a series of intermediate languages into code that runs on a virtual machine. In this course, you’ll build both a Universal Forward Translator and a Simple Virtual Machine.

You’ll build as part of a learning community that can freely share ideas and even code. The implementations you build will be useful by themselves and will be fun to extend further. And creating them will develop both your machine-level programming technique and your functional-programming technique.

What background do I need?

To succeed in the course, you’ll need two kinds of background:

Parts of the SVM will be specified using operational semantics, at the level covered in COMP 105. If you haven’t had 105, don’t worry; the semantics are there to clarify details, and you’ll be able to work effectively without them.

How will we study the topic?

The course will be organized as follows:

What will happen in labs?

Lab will look a lot like recitation for COMP 105: you’ll work in teams of two or three on problems directly related to homework. There are three important differences:

What will happen at code review?

Code review has two purposes:

Code review will take two forms: Small-group code review will involve two or three students mutually reviewing each other’s code for about 30 minutes. Plenary code review will involve a team presenting to a review panel composed of three students, which the whole class will observe.

Classes devoted to code review will also have time for general questions.

What does small-group code review look like?

Small-group code review will be based on the answers to three questions that are required with every homework: what you are proud of, what you want help with, and what you would like the instructor to review. These questions will be the focus of small-group work with two other students. Each student’s code will be the center of attention for about 10 minutes, for a total of about half an hour. There will be no written record.

Unless we find a better setting for small-group work, small-group review will take place in Zoom breakout rooms.

What does plenary code review look like?

Plenary code review is a more heavyweight process: one project gets everyone’s attention for half an hour. Plenary review will take place in a single Zoom meeting with shared screen, which the whole class will attend. In order to help the most students, pair work and group work will be prioritized—but solo contributors will probably also have opportunities to have their work reviewed in the plenary setting.

Plenary review divides the class into three parts: the contributors, who have collectively written the code under review, the panelists, who evaluate the code under review, and the class, who watch and learn. Contributors have these roles:

In order to give everyone a chance to learn what it is like to present code, the instructor may sometimes ask a different contributor to take over the presenter’s role.

Panelists identify problems and good practices. (Every code base has problems—we’ll find them.) Panelists need not propose fixes. The three panelists have these roles:

The presenter and the panelists speak aloud. The rest of the class are encouraged to add questions, challenges, and interjections to the Zoom chat window. At need, the course staff will bring chat contributions to the attention of the moderator.

Presenters will do all of the following:

Panelists will be given a set of recommended prompts.

Who presents? Who’s on the panel?

Everyone will get a turn in both roles. We’ll take volunteers first, and we’ll draft people as needed. Early volunteers will earn bonus participation points.

Panel reviews? Has Norman lost his mind?

We’re trying to help everyone become more thoughtful engineers, and we especially want to help everyone learn to think clearly about code. The most effective way I know to do this is through structured, supervised code reviews. And I promise that you will find it fascinating to see, in depth, how other students have tackled problems that you yourself are working on.

Code review is hard to do well, but good code reviews will teach you more about coding, more deeply, than you could learn in any other way. If you can think about code that other people have written, and if you can write your own code so that others can easily think about it, you will have acquired an invaluable skill.

I have done code reviews in other courses, although they have been smaller than our course (10 students instead of 20). We all learned that it’s really cool to see how other people approach problems. We also learned that presenting our technical work in front of others can be intimidating. It gets easier with practice. A good semester of code review will teach you a lot, and the practice will help you significantly in your job interviews.

Code reviews may be difficult to get started, but if we lean on the strong collaborative culture that is established throughout most of the Tufts CS department, we should be able to craft a good experience for everyone. I’m counting on you.

How will I need to prepare before class?

Our time in labs and at code reviews is precious, and you’ll need to hit the ground running.

What are pandemic-mitigation hours?

Let me quote from an opinion piece by Olivia Judson, which appeared in the New York Times on March 16, 2020:

The idea is that at fixed times of the day, you log onto Zoom, Skype or some other tool for online video conferencing. Other people log on too, and after a couple of minutes of structured chat—on which, more in a moment—everyone hits “mute” on their microphones and the session begins. Video on, sound off. As I write this, I’m in a Zoom Room with two others; I can see them in the corner of my screen. Both have expressions of absorbed focus. I suspect that I do too.

When I mention this to friends, some get it while others find the whole idea absurd. “Wow, that’s really postmodern,” one said to me. “Do you want to be watched?” No, it’s not the watching. It’s the sense of camaraderie, the esprit de corps.

I’m offering two sessions of one hour each. When a session ends, each participant is invited to say how they did. Examples from Judson: “I totally rocked this project!” “I didn’t finish, but I got into flow.” “I set up three client calls.” “I noticed that when I put my phone away, I got more done.”

A pandemic-mitigation hour is for any work you want to get done—not necessarily for this class. And I’ll take (silent) questions via chat.

What is the course’s camera policy?

Although we’ll meet in the 150VM Workroom in Virtual Halligan Main, our labs and code reviews will take place via Zoom. During labs, cameras are encouraged but not required. Small-group code reviews likewise.

During a plenary code review, the presenter and the three panelists must have their cameras on—the interaction can be intense, and it would not be fair for it to be faceless. The rest of the class are encouraged to have their cameras off so that the presenter can use the Zoom “gallery view” and see only the panelists.1

During pandemic-mitigation hours, cameras are strongly encouraged. The idea is for your presence to encourage others to work. But if the camera is a problem for you, we will find a way to work without it.

How will I work with my peers?

Interactions during labs and code reviews will take place as described above. Interactions around homework will depend on how you wish to work. The project is ambitious enough only rare individuals are likely to complete an entire SVM and UFT working on their own. I encourage you to work with a partner. Working with larger groups is also permitted, although I’m not sure the project offers enough scope for a larger group.

Here are the ground rules:

To help you decide with whom to work and how long, I recommend this heuristic: if you are having a great experience, keep doing what you are doing. If you are just having a good experience, try changing something. And if you ever have a bad experience, please come talk to me.

How should I organize my work, especially with partners?

You have a lot of freedom. I recommend that you use it like this:

  1. Each module assumes that you have working code from previous modules. But it doesn’t have to be your code. Code from previous modules is rarely edited, so if you want to, you can usually plug in somebody else’s code. I therefore recommend that you begin each module, before the Wednesday lab, by consulting your partners and planning what code you’d like to keep from the previous week—and what you might like to replace with someone else’s code.

  2. Each module includes a lab, the results of which will be part of your homework. You can think of the Wednesday lab as a well-supervised “start the homework” session. Prepare for the lab ahead of time, and plan to do it with a partner. (For the first few labs, the course staff will pair you with a partner whose skills and interests align with yours. For later labs, you will choose.)

  3. Each module lists 8 or 9 things you should plan to learn, or skills you should plan to demonstrate, while doing the homework. These are the module’s learning outcomes. At the end of the lab, identify which parts of the homework seem essential to the learning outcomes. If you’re working on a team, those parts should either be pair programmed or should be split in such a way that all team members get to claim learning outcomes. (For example, if the team needs to implement a dozen VM instructions, each member could independently implement a half-dozen instructions, and all could credibly claim learning outcomes associated with those instructions.)

  4. Not every piece of code you write is going to contribute equally to learning outcomes. For example, in the first module, it’s essential that you learn the basic technique for implementing VM instructions, but once you’ve done something like an add instruction, you’re not going to learn a lot more from doing subtraction, multiplication, and division. But they still have to be implemented. Code like this, which is necessary for the project but is not necessarily essential to learning outcomes, can be implemented either in partnership or by one or another partner independently. If your implementation choices permit it, you can even crowdsource such code to the whole class.

How will I get software? How will I submit?

Software I provide will be available in a private git repository hosted on gitlab.cs.tufts.edu. I encourage you to maintain your own code in a git repository, but because git is such a usability train wreck, I don’t want to mandate it. So you’ll submit from the department servers using the venerable provide.

As for other software, C and Standard ML are already installed on the department servers. I do recommend that you install these languages on a machine of your own, however—the development experience is so much better.

If you are using Emacs, I highly recommend the magit package. It actually makes git pleasant to use—an outcome I thought was not possible.

Where will we meet?

For synchronous meetings, including pandemic-mitigation hours, we will be in the 150VM Workroom on the main floor of Virtual Halligan. Use the link, or log into https://tuftscs.sococo.com/ using your University login credentials (“unified login (SAML)”).

Virtual Halligan works with the Chrome web browser and with Sococo’s desktop platforms for Windows or the Mac (Enterprise Login with tuftcs.sococo.com as the domain). It does not work on other browsers or on mobile platforms.

Asynchronously, we will be on Slack (as requested by the majority of students in the pre-course survey).

Virtual Halligan is built on a platform called Sococo, which may not work for everyone. But don’t worry—synchronous meetings will be held via Zoom, and there will be a link in Slack as well as in the 150VM Workroom.

How will I keep track of everything?

The course has a lot of activities and deadlines, and yet, when all classes are online, everything looks the same. To help you keep track, I recommend the course calendar.2

How will grades be determined?

Grades will be determined by a point system. The system is complicated, but it’s meant to be transparent: at all times, you should be able to be in control of and aware of your grade. Because the system is unusual, you deserve to be aware of the rationale behind it:

  1. I want everyone to do the project.
  2. I want everyone to contribute to code review.
  3. I want everyone to get an A.

In addition, I want to simulate real-life conditions: if you’re implementing a programming language, you won’t have an instructor to tell you if the code is right. In fact, I don’t really care if your code is right—I care that you do the project thoughtfully.

To meet all of my goals for the course, I’ve designed a new grading system. I do believe it will meet the goals, but it’s not simple. The grading system is based on points, which you can earn in three categories:

Project points and participation points are essential, but to earn an A or an A-plus, you also have to demonstrate depth. The number of points you earn determines your grade; each grade has a minimum requirement in each category:

Minimum point values needed for each grade
Grade Project Participation Depth
A+ 96 96 10
A 92 92 5
A- 90 90
B+ 87 87
B 83 83
B- 80 80
C 70 70

If you earn more points in one category than another, you can trade them as follows:

The costs are set up to make the project worth 80% of your grade and participation worth 20% of your grade. You don’t actually have to execute any trades; my software will trade points automatically in a way that maximizes your grade.

How do I earn project points?

In each module, you earn project points from your Monday-night reflection, which in turn is supported by your Sunday-night homework. Each module has a section labeled “learning outcomes.” In that section you will find 8 or 9 bullet points, each describing a thing you are hoping to do or hoping to learn. Here are some examples:

Each learning outcome—that is, each bullet—earns one project point. You’ll have the learning outcomes in mind when you craft the code you’ll submit on Sunday. Then after 24 hours, on Monday night, you’ll submit a reflection that lists the outcomes you’ve learned. You’ll support each learned outcome with a short sentence or two, sometimes just a pointer to your code. The deadlines are designed so that learning outcomes can be discussed in Monday’s code review.

Project points for a module are earned based on the homework submitted for that module and on the corresponding Monday-night reflection. Unless they are so marked, a project point can’t be carried forward to a future module.

At the moment, there are a total of 100 opportunities to earn project points. If it looks like it might be hard to get to 92 points, I will add more opportunities.

Some points can be earned more quickly than others, but if you earn all the available points for the course, I guess that it might take you around an hour and twenty minutes per point. That’s a very rough estimate; our data from COMP 105 show that the time students report spending typically varies by a factor of 4. You are part of a self-selected group, so I am not expecting that much variance, but a factor of 2 would be unsurprising.

How do I earn participation points?

Participation points are earned for activities you do every week, like small-group code review; for activities you do occasionally, like serve on a code-review panel; or activities you do once, like complete a survey. Each category earns points up to a fixed maximum, as listed in this table:

Participation points
40 The course finale (once)
15 Presenter at plenary code reviews (occasionally)
10 Panelist at plenary code reviews (occasionally)
12 Participation in peer code reviews (weekly)
10 Code-review reflections on homework (weekly)
10 Material responses to code review (occasionally)
3 Timely course surveys and intro video (once)

The algorithm for earning participation points is where things get complicated:

Everyone can be confident of earning full credit for participation. If I’ve done the arithmetic correctly, you can earn 100 points through mechanisms that are totally under your control: If you show up every week, take your turn at plenary code reviews, and generally do what’s expected, you’ll earn 60 points. You’ll earn 40 points for a successful course finale. That’s a total of 100, without any bonus points. If you do earn bonus points, either through early volunteering or by having your peers acknowledge you for help that you give them in code reviews, they add to your total.

How do I earn depth points?

Everybody is doing the same project, but not everybody has the same interests. Depth points offer you the opportunity to earn a top grade by demonstrating depth in an area that you choose. Depth points will be available in multiple modules, and when possible, depth points will be available for interests that you identify in the pre-course survey.

Depth points are earned by completing depth goals, which might look like this:

Unless a depth goal is marked with an expiration date, depth points can be earned by completing the goal any time before exams begin. Unless otherwise marked, a depth goal is not limited to the module in which it appears.

To earn an A or A+ you need 5 or 10 depth points, which you can earn by completing a few small goals or one bigger goal. The point rewards are meant to be tuned so that earning a depth point takes about an hour.

What if I can’t deliver my work on time?

Because the project is so cumulative, I really recommend that you don’t get behind. To make it easy to submit your homework on time, I’ve set things up so you get points not for complete, working code, but for your ability to articulate what you learned from writing the code. If you’ve built a thing and you understand how it’s put together, but it doesn’t quite work yet, go ahead and submit it on time. You can debug it later.

That said, I’m offering a limited late policy somewhat similar to the late policies for COMP 40 and COMP 105:

What if I’m too sick to submit work?

The pandemic heightens the risk that you may get too sick to work. And the project is very cumulative—what are you going to do? Just let me know. It’s a small class, and I want everyone to get an A. I will work with you to make that possible, in a way that is fair to you and also fair to your classmates.

This policy applies to any significant illness, not only to COVID-19.

What’s different because the course is online?

Not much. The course was designed from the beginning to be based on labs and code review, with no lectures. Likewise, the grading is designed to meet my three main goals (project, code review, A’s) which are the same whether we are online or not.

The main differences are these:

How will the course end?

In lieu of a final exam or paper, you will experience a team-based “course finale,” which will be scheduled during final-exam period. It will work like this:

Acknowledgements

Annie Soisson suggested a course finale in lieu of an exam or paper, and she helped me work out some of the details. Matthias Felleisen, who has many years of experience doing code reviews with students, explained to me how his code reviews are structured; I have borrowed several of his practices. Jacob Matthews suggested why code review might be important.


  1. Right click on a text name and select “show only participants with video.”

  2. If there is demand, I can try to produce a calendar in machine-readable form. Let me know.