Final ProjectsSome project suggestions are posted on the moodle and may be updated during the course of the semester.
Students are expected to select and complete a substantial course project during the semester on a topic related to the class.
Projects should be done in groups of two (though individual or three-person projects may be discussed on a case-by-case basis). The expectations will naturally depend on the number of group members.
The first step is to submit a project proposal. The proposal should explain what you expect to learn from the project (i.e., why is it interesting to you?) and should include a work schedule. Make sure to budget time for writing a short project paper (~5 pages) describing the project and for preparing a short (~15-20 minutes, depends on number of projects) project presentation during the last week of classes. The project proposal should be one or two pages long. The main purpose of the proposal is for me to give you feedback on its feasibility.
The main goal of the project is to allow you to customize the content of the course to your own interests. The goal is not to force you all to produce novel results in one semester. Course projects like this often lead to collaborations that eventually yield exciting research. In the hopefully-likely event that you end up enjoying your project, come see me about taking it further (say, to publication).
- The 1-page project proposal is due on Sunday, March 14, 2010.
- A project status update is due on Tuesday, March 30, 2010.
- Project presentations will be held during the last week of classes. During the month of April, I will announce a schedule of presentations.
- The project paper is due on Wednesday, May 5, 2010.
- Peer reviews on project papers are due on Thursday, May 6, 2010.
I do not expect each project to lead to novel results, though I hope some projects will lead to publication!
- I do expect a consistent effort on the project. Once we stop having weekly homework assignments, that amount of time should be entirely directed towards your project.
- Notably, "one long weekend" will not suffice. I can tell. Trust me.
- You are welcome to tackle a more ambitious project. Such a project should have "stages" so that you have something to show at the end of the semester. I (or your advisor) can provide extra guidance on such projects.
- The number of group members should depend on the size of the project. The ideal size for most projects will be two persons. Note that the grading for a two-person project will actually require "twice as much work" rather than the standard "1.5-times as much work". You should be able to split up the project paper (e.g., "I did section 1, Grace Hopper did section 2, and we shared section 3"), and I should be able to compare your part of the project to individual projects.
Projects on any subject related to the class are acceptable. The goal is to allow you to customize the project to your interests. There are three main types of projects: research projects, survey projects, and implementation projects.
In general, I recommend that you try to do a research project. They are typically a bit harder but much more rewarding than either survey or implementation projects.
There are many kinds of research projects, including the following:
- Design and implement a program analysis
- Invent a language or a language feature for some particular purpose or with some particular characteristic (e.g., to make program analysis and understanding more tractable)
- Try to formalize some interesting aspect of some existing language
- Explore novel techniques for implementing a given language fragment
These projects are harder because they always involve some survey work and often involve some implementation. If you want to do a research project, and you are not yet sufficiently familiar with the area of the project, you should start with a brief survey and then turn it into a research project. While research is necessarily open-ended, be sure that you have a well-defined goal for the end of the semester so that you have something to write up and present.
Pick an area in which you are interested. Read at least six papers thoroughly and at least six other papers "superficially". I will help, but you should do most of the work in finding the relevant papers. Then, write a paper on what you have learned:
- What are the basic problems in this area?
- What are the basic approaches to solving them?
- What are the main achievements to date?
- What are the open problems?
- What further research or experiments do you propose in this area? Why?
Keep the scope narrow enough so that you can say something interesting. Please do not pick an area that already has good survey papers available (or be sure to provide evidence to me that your survey will be different in some way).
Pick a fragment of a language or a relevant algorithm, and implement it! There is no firm limit on the amount of code.
An implementation project should feature "numbers": controlled, experimental results that help to sway your audience in favor of a point you are making. You should actually have a point: "I implemented a register allocator" is not quite good enough. You will want something more like: "Graph-coloring register allocation yields fewer spills and thus smaller and faster code than greedy register allocation. On the X benchmarks for the Y architecture, replacing a greedy register allocator in the Z compiler with a graph-coloring one resulting in a A% decrease in code size and a B% decrease in average executing time."
Your implementation must be relevant to language design or analysis. It could also be relevant to language implementation, provided that it has sufficient conceptual content and is close enough to the course. Graph-coloring register allocation wouldn't actually cut it.
The Status Update
The Status Update is a short write-up (less than one page). It should explain what you have done so far and how you plan to meet your goals in the final month of the project.
The presentation should be short and should describe what the problem was, what the difficulties were, and what was accomplished or learned. You will find it much easier to prepare the talk using slides (perhaps 8 to 15 slides, depending on your speed).
While preparing the talk keep in mind who your audience is. You will be presenting to colleagues who are eager to find out (1) about new exciting facets of programming languages and (2) how much fun you had. Plan to motivate the project (i.e., why is this important?) and to describe what you learned from it. Keep in mind that your colleagues have not read all the papers that you have read to do the project.
Project presentations will be held on Tuesday, April 27, 2010 and Tuesday, April 29, 2010. Students presenting on April 27 will receive a small amount of extra credit to make up for presenting earlier.
Logistics. Each presentation slot will be approximately 12 minutes, so you should prepare a talk that is 10 minutes in length leaving 2 minutes for questions. To keep things moving smoothly, you should plan on using my laptop for the presentation if possible. You may use your own laptop if you plan on showing a demo or using presentation software that I do not have, but let me know in advance. I have PowerPoint 2007, Keynote, OpenOffice Impress, and a PDF reader on my laptop. On the day of your presentation, upload your slides to the moodle at least 30 minutes before class.
Your write up at the end of the semester should be in the form of a short research paper. The project paper should have an abstract and an introduction describing the tackled problem, its motivation, and a very brief summary of the accomplishment. Then you should write a description of your notations (especially if they are different from what we used in class). Then you continue with the body of the material. The paper should end with a conclusion putting in perspective the accomplishment of the project and mentioning the open problems and with a bibliography of cited papers. Research and implementation papers should also have a related work section in which they compare the work with previous research results.
You should write your project paper as if you were submitting it to, for example, the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI). You might want to browse the papers from PLDI 2009 or POPL 2010. Aside from giving you a number of data points for how the paper should look graphically, reading the electronic editions might help you to find a topic. Extending previously-published work is often not a bad start.
Your project paper should be 5-10 pages, as necessary. You will turn in a PDF as well as your sources. You will want to use the LaTeX class file or Word template produced by SIGPLAN.
Peer Review. You will have the opportunity to write reviews of your peers' project papers for extra credit. Take a look at the Paper Review Form for further details.
All homework must be completed individually. You may discuss the problems with others, but you must turn in your own work. If you discuss the problems with someone, you must cite them (following the collaboration policy).
Homework solutions should be submitted on the course moodle by 11:55 p.m. on the due date. Your write-up should be submitted as a PDF file along with any code (if applicable). Either a typeset or a handwritten write-up is acceptable.
Homework Assignment 7
Due Thursday, March 18, 2010.
Homework Assignment 6
Due Thursday, March 11, 2010.
Homework Assignment 5
Due Thursday, March 4, 2010.
Homework Assignment 4
Due Thursday, February 25, 2010.
- Handout (updated on February 19, 2010 with more details and hints, updated on February 22, 2010 with a few more details)
- LaTeX sources
Homework Assignment 3
Due Thursday, February 18, 2010.
Homework Assignment 2
Due Thursday, February 11, 2010.
Homework Assignment 1
Due Thursday, February 4, 2010.
- Code pack
- OCaml manual. OCaml works on most platforms.
- If you are using LaTeX, there are two fairly popular packages for typesetting inference rules: mathpartir.sty by Didier Remy and proof.sty by Makoto Tatsuta.
Homework Assignment 0
Due Thursday, January 28, 2010.
- BLAST project. You will need to download BLAST version 2.5. Do not use the Cygwin version.
- BLAST manual
- tcas.i test case. TCAS is an implementation of a traffic collision avoidance system by Himanshu Jain.
- If you don't have a Linux machine yourself, you can
It is important to attend class and read the readings.
Class participation includes in-class participation, as well as participation in the discussion forums on the course moodle. All enrolled students are required to post at least 1 substantive comment, question, or answer on each lecture and reading set. Initial comments, questions, or answers for each lecture must be posted the night before the next meeting (i.e., comments for Tuesday's meeting must be posted by Wednesday night, and comments for Thursday's meeting must be posted by the following Monday night). The goal is to identify concepts that need reviewing in the subsequent class.
You may and are encouraged to post comments or questions about the reading before the class where we will cover it. Posting early will help focus our discussion.
In place of class participation, CAETE students are expected to participate more heavily on the discussion forums (e.g., at least 1 extra substantive comment than required for everyone each week).
Here are some examples of good comments:
- Questions about the reading or the class discussion.
- Thoughtful answers to other people's questions.
- Clarification of some point discussed in class.
- What you think is the main point or key idea in the reading set.
- An idea of how some work could be improved from the reading or class discussion.
- Comments on a web resource related to a reading or class discussion (e.g., you happened upon an interesting blog post related to our discussion).
The intent of the forum post is definitely not to have you perform extra reading or web searching, but rather to take a moment to reflect upon the day's reading or class discussion.