Hi, friends! This fall will be my first quarter teaching at UC Santa Cruz! I’m very excited to announce that this fall I’m teaching a graduate seminar on one of my favorite topics: languages and abstractions for programming distributed systems.
Here’s an “official” course description:
This graduate seminar course explores the theory and practice of distributed programming from a programming-languages perspective. We will focus on programming models, language-level abstractions, and verification techniques that attempt to tame the many complexities of distributed systems: inevitable failures of the underlying hardware or network; communication latency resulting from the distance between nodes; the challenge of scaling to handle ever-larger amounts of work; and more. Most of the work in the course will consist of reading classic and recent papers from the academic literature, writing short responses to the readings, and discussing them in class. Furthermore, every participant in the course will contribute to a public group blog where we will share what we learn with a broader audience.
There are a lot of reasonable ways to approach a seminar course on languages and abstractions for distributed programming. We could spend the whole ten weeks on process calculi and still only make a small dent in the literature. Or, we could spend ten weeks on large-scale distributed data processing and still only make a small dent in the literature.
In this particular course, we will be focusing a lot of attention on consistency models and language-based approaches to specifying, implementing, and verifying them. (Of course, we will only make a small dent in the literature.)
What’s this about a blog, then?
As a grad student, I always dreaded having to do course projects. In an ideal world, these projects were supposed to dovetail nicely with one’s “real” research, or they were supposed to morph into “real” research within three months by some mysterious alchemical process involving lots of luck and suffering. In practice, they usually ended up taking time away from real research, and they always ended up being hastily implemented and shoddily written up. The code was almost never made public, and if it was, anyone who tried to get it to run a few months after the course ended would most likely be in for a bad time.
So, we’re going to attempt something different. Instead of a traditional course project, each student in the course will write (and illustrate!) two posts for a public group blog aimed at a general technical audience. The goal is to create an artifact that will outlive the class and be valuable to the broader community.
Will this be less work than a traditional course project? No. A blog post requires substantial work (reading, writing, editing, programming, debugging, thinking, …), and I’m asking students to expect each post to take about thirty hours of focused work. Furthermore, every student in the class will serve as an editor for two posts other than their own. The job of the editor is to help the writer do their best work — by reading drafts, asking clarifying questions, spotting mistakes and rough spots, and giving constructive feedback. This will take another five hours or so per post.
Altogether, it’s a pretty big time commitment, but one that I hope students will find worthwhile.
So! If you’re a computer science grad student at UC Santa Cruz, check out the course overview and draft reading list, and consider signing up to take the course! And if you’re not a computer science grad student at UC Santa Cruz, but you think you want to be, then get in touch — I might be able to help with that.