CS 242: Final Project

Adapted from CMU’s 15-418 final project page.

The final project for this course will be an exploration into the usage or implementation of advanced features in programming languages. This could be either an extension of what we looked at in class or something entirely new—that’s up to you! The goal is to allow you to use the foundations/skills acquired in class to understand a topic in programming languages of personal interest to you.

Check out the projects from Fall 2017.

Schedule

Sunday, November 5th (11:59pm) - Project proposals due
Friday, December 1st (11:59pm) - Project checkpoint due
Thursday, December 14th (11:59pm) - Project report due
Friday, December 15th (3:30pm-6:30pm) - Project presentations

No late days can be used on any of these deadlines.

Choosing a project

On a high level, a final project should relate back to at least one of the themes of the course:

Expressiveness: How can we capture common programming patterns in language constructs? What aspects of a language make programmers more productive?
Correctness: How can we ensure the safety of a program (i.e. no segfaults, crashes, out-of-bounds, …)? What properties of a program can we know or infer before ever executing the code?
Performance: How can we design language constructs to efficiently map to hardware or to easily parallelize computations?

Amongst these themes, the most interesting questions tend to explore the tradeoffs between them. How can we capture the ease of dynamic programming idioms without losing the safety of static typing? How can we prove correctness in the face of a complex underlying runtime like a CPU? How can we ensure good performance in the face of complexity introduced by expressive language constructs? Your final project should be a deep dive into a small slice of one of these kinds of questions.

Here’s a few examples of what a good final project could be:

Write the most efficient class implementation possible in Lua and do a thorough benchmark comparison to your assignment 2 solution. Demonstrate how your code is faster and why. Add an additional feature like multiple inheritance and analyze its runtime impact.
Investigate the usage and implementation of generalized algebraic data types in OCaml. Create nontrivial applications with GADTs and gain an understanding of when to use them. Present a formal semantics for using GADTs in the lambda calculus as well as a proof of progress and preservation.
Conduct a user study comparing the productivity and debuggability of a dynamically typed and statically typed language (e.g. JavaScript and Java) when implementing a particular application (see: related work). Perform a qualitative (e.g. interviews) and quantitative (e.g. time to completion, number of bugs) evaluation to highlight user preferences and impact on software development.
Design and implement an efficient graph processing library in Rust. Compare and contrast different approaches to memory management in your library and evaluate their effects on usability and performance.

Requirements

Your project must adhere to the following requirements:

Projects may be done either individually or in a group of two (but no more).
We’re going to be pretty flexible on what you can choose for a topic, but it should be principally relevant to the themes of the course as mentioned above.
You will have three weeks to work on the assignment (technically five including Thanksgiving and finals week), so we expect a minimum of 20-30 hours of work per student on the project, and the difficulty of your project should reflect that.
During the our final, you will provide a brief presentation of your work to the rest of the class. This presentation is primarily to educate your classmates on the interesting parts of your problem and solution. You will also create a 3-4 page final report explaining the problem, process, and results.

Proposal (5%)

The purpose of the proposal is both to help you organize your ideas about your project as well as provide us an opportunity to offer feedback. Your proposal will be a PDF with the following sections and content:

Title. Provide the title of your project followed by the names of all team members.

Summary. Summarize your project in no more than 2-3 sentences. Describe what you plan to do and what language concepts you will be dealing with.

Background. Describe any relevant background to understanding the context for your project. If you are working on a specific application, explain its structure and its relevance to programming languages.

Challenges. Explain why your project is challenging. How complex are the language concepts you’re dealing with? Are there any aspects of the project that deal with open problems? What do you hope to learn by doing the project?

Resources. Describe the resources (type of computers, starter code, etc.) you will use. What code base will you start from? Are you starting from scratch or using an existing piece of code? Is there a book or paper that you are using as a reference (if so, provide a citation)? Are there any other resources you need, but haven’t figured out how to obtain yet? Could you benefit from access to any special machines?

Goals and deliverables. Describe the deliverables or goals of your project. This is the most important section of the proposal. Separate your goals into what you plan to achieve (what you believe you must get done to have a successful project and get the grade you expect) and an extra goal or two that you hope to achieve if the project goes really well and you get ahead of schedule, as well as goals in case the work goes more slowly. State clearly the metrics by which we should evaluate your project. How can you demonstrate that you did a good job? Will it be an interactive demo, a performance evaluation, a user study, a formal proof, or something else?

Schedule. Propose a schedule for your project breaking down each week until the final presentation. List what you plan to get done in order to meet your project goals. Keep in mind that due to other classes, you’ll have more time to work some weeks than others (work that into the schedule). You will need to re-evaluate your progress at the end of each week and update this schedule accordingly. In your schedule we encourage you to be as precise as possible. It’s often helpful to work backward in time from your deliverables and goals, writing down all the little things you’ll need to do.

To submit your proposal, one of your team members (only one, not both) should submit your PDF with the name <sunet id>.pdf (or <sunet id1>-<sunet id2>.pdf) by copying it to Rice and running:

cp <your file>.pdf /afs/ir/class/cs242/submissions/proposal/

Checkpoint (5%)

The purpose of the checkpoint is to provide you a soft deadline for mid-way goals in your project as well as for us to verify that your group is making progress. Your goal in the writeup is to assure the course staff (and yourself) that your project is proceeding as you said it would in your proposal. If it is not, your checkpoint writeup should emphasize what has been causing you problems, and provide an adjusted schedule and adjusted goals. If we feel like you need serious course-correcting, the member of the course staff in charge of your project may request an in-person meeting. In writing your checkpoint, consider the following:

Provide one to two paragraphs, summarize the work that you have completed so far.
By this time you should have a good understanding of what is required to complete your project, so we should see a very detailed schedule for the coming weeks. We suggest breaking time down into half-week increments. Each increment should have at least one task, and for each task put a person’s name on it.
Describe how you are doing with respect to the goals and deliverables stated in your proposal. Do you still believe you will be able to produce all your deliverables? If not, why? What about the “nice to haves”? In your checkpoint writeup we want a new list of goals that you plan to hit for the final presentation.
What do you plan to show at the final presentation? Will it be a demo? Performance graphs? How should you be evaluated?
Do you have preliminary results at this time? If so, it would be great to included them in your checkpoint write-up.
List the issues that concern you the most. Are there any remaining unknowns (things you simply don’t know how to solve, or resource you don’t know how to get) or is it just a matter of coding and doing the work?

Send your checkpoint in an email to the member of the course staff in charge of your project.

Report (70%)

Your final report should include the following basic sections. Not all the sub-bullets apply to all projects, but they are given as examples/suggestions of issues to address. You are also encouraged to provide more detail if you wish. Note that some of the information in your final writeup can be pulled directly from your proposal if it is still accurate. You should use the ACM template for your report, and the report should probably be at least 4-5 pages (there is no maximum).

Summary: A short (no more than a paragraph) summary of the challenge, results, and evaluation of your project.
Background: Describe any relevant background to understanding the context for your project. Figures are useful here.
- What is the challenge you tried to address?
- What are the alternatives? (describe status quo/state of the art)
- How does this problem relate back to the themes of the course?
Approach: Explain how attempted to address the challenge of your project.
- Did you build a system, perform an experiment, learn about new techniques, or something else? (Note that these are not mutually exclusive, e.g. building a system likely involves running an experiment.)
  - If you built a system, describe its design. Figures recommended.
  - If you performed an experiment, describe the experimental setup. What were you trying to evaluate? How does the setup control for other variables? Note that “experiment” includes any kind of project oriented at comparing multiple languages, frameworks, programs, and so on.
  - If you learned about a new technique, describe the learning process and what you built during that process.
- What was the initial reason for picking the approach you did?
- If your project involved many iterations, please describe this process as well. What did you try that did not work? How did you arrive at your solution? The notes you’ve been writing throughout your project should be helpful here. Convince us you worked hard to arrive at a good solution.
- If you started with an existing piece of code, please mention it (and where it came from) here.
Results: How successful were you at achieving your goals? We expect results sections to differ from project to project, but we expect your evaluation to be thorough.
- Describe the metrics for evaluating your solution and the alternatives. If you built a system, how can you determine that it’s solving a problem? If you ran an experiment, you should have described the experimental setup/goals in the previous section. If you learned about a new technique, how do you evaluate the efficacy of what you learned?
- Where possible, present quantitative data supporting your results. If something should be faster, describe how you measured performance and justify why the comparison is fair. If something should be more correct or more expressive, providing numbers can be tricky (e.g. lines of code is often a poor proxy for whether something is expressive, and more generally there are not many well developed metrics in this area), so if not possible, provide a qualitative report of your experience with the tools you’ve built or evaluated.
- Provide an analysis of why you think you got the results that you did. Why was framework X faster than framework Y? Why was it harder to write code in one language versus another? etc.
References: Provide a list of references used in the project.
List of work by each student: if your project is a team project, please list the work performed by each partner. Alternatively, you can simply state: “equal work was performed by both project members.”

To submit your report, using the same naming convention as the proposal (<sunet id>.pdf or <sunet id1>-<sunet id2>.pdf), upload your report as a single PDF file to Rice and run:

cp <your file>.pdf /afs/ir/class/cs242/submissions/report/

Presentation (20%)

The purpose of the final presentations is twofold: first, it provides you an opportunity to educate fellow students (and the course staff!) about what you learned in your project. Second, it encourages you to think about how to present your results in a concise, understandable way via live presentation. Each team will do one presentation, and the presentations can be no longer than 6 minutes (with an additional 2 minutes provided for questions). You’re welcome to use slides, provide a live demo, or use any other media for communication where appropriate. If yours is a team project, then both members should have equal speaking time.

On the final presentation day, the talks will be organized in a conference style where we will run three rounds of four concurrent sessions per round with 4-5 talks per session. The presentation schedule will be provided to you during finals week. During each round, you must attend a session, but it’s up to you to decide which is most interesting to you.

Sections