• Checkpoint: Teams and Topics 5:00pm Friday 13 November
    • Form teams and meet with Ben to choose a topic no later than this time.
  • Checkpoint: Background Research and Plan 11:00pm Tuesday 1 December
    • Complete background research on project topic and submit initial background section.
  • Checkpoint: Presentation and Artifact 9:50am Tuesday 8 December
    • Present project area and artifact so far.
  • Due: Paper and Artifact 4:00pm Friday 18 December
    • Submit paper and completed artifact.
  • Submission:
    • Store your code and documents as source files or PDFs in a repository and add bpw as admin.
    • You may store the paper as a Google Doc if you prefer. (Share with me.)
  • Collaboration:
    • The final project falls under the group collaboration policy. You may complete a single project alone or with one or two teammates. Teams are encouraged. You may discuss high-level ideas with other teams, but your projects will naturally differ. If working in a team, the final product must represent roughly equivalent effort on the part of all team members. You are not required to work on all parts together (as in some other assignments), but your project should form a unified whole.

Goals and Topics

The final project requires you to learn, use, and analyze one or more programming languages, programming models, or program analysis tools that are new to all members of your team and that differ sufficiently from those we have studied in this course. The “sufficiently different” bar is hard to define succinctly in text, so you will develop your project plan with input from me.

Goals of the project:

  • to apply the manner of critical thinking about programming language semantics that we have developed this semester
  • to learn a new language/model/analysis or significantly deepen your understanding of one we only skimmed
  • to analyze the semantic and design choices of a programming language/model/analysis and:
    • weigh trade-offs in support of clarity, extensibility, modularity, convenience, reliability, etc.
    • compare semantics and design decisions with a more familiar language/model/analysis
  • to build or check programs with this new language/model/analysis
  • to share what you learn with your classmates so we can experience a breadth of additional programming language designs

To help find a reasonable and feasible project (and to help achieve this last goal), you will develop your project plan with my input. I will try to guide you to a topic that matches your interests and complements a wide range of topics among teams. If you are passionate about an idea that is 251-related but does not strictly fit the outline given here, please consult with me to see if we can make a reasonable project plan. The exact balance of the different parts of the project will depend on the topic you pursue. I will calibrate that for each team.

Suggested topics (beyond other languages) include:

  • Logic programming languages such as Prolog.
  • Domain-specific languages or frameworks.
  • Dynamic program analyses for bug-finding.
  • Information-flow tracking or control.
  • Static program analysis or type-checking tools and algorithms.
  • Gradual typing systems, such as Facebook Flow.
  • Languages and tools for program verification, such as Coq.
  • Effect systems.
  • Programming with continuations.
  • Software transactional memory in Scala, Haskell, or Clojure.
  • Type classes, laziness, monads for containing and emulating side effects in Haskell.

Some of these topics come with natural choices for software artifacts to build. If there is no artifact currently on your list of “things you want to build,” a good default is an interpreter for a simple language.

Stages

The project officially runs for over a month, and is divided into several stages. Regular assignments will continue through the end of classes, but will be somewhat lighter weight to allow time for concurrent project work. This section defines the project stages. The timeline at the top of this document lists the due date for each stage.

Teams and Topics

Begin by forming a team of 1-3 students and discussing your interests or project ideas with your team. Singleton teams are allowed, but working with a partner is encouraged. The expected scope of projects grows somewhat with team size. Well in advance of the Teams/Ideas Checkpoint, send me one email per team listing:

  • Your team members.
  • Specific project topics or general areas you are interested in pursuing.
  • Programming artifacts you would like to build.
  • Your team’s availability for a meeting in the week preceding the checkpoint (or earlier).

We will schedule a team meeting ahead of the checkpoint. At this meeting, I will help you focus your interests and ideas into a feasible, reasonable, and interesting project outline that is more specific than just “play with language X.” Following our meeting, you will submit a <1-page project outline ahead of the checkpoint. The outline should include:

  • The programming languages, programming models, program analyses, specific features, and design choices you plan to explore
  • Programs or styles of programs you plan to write to aid in this exploration
  • Resources for initial research on language/model/analysis semantics
  • Timeline and plan for division of work

Background Research and Plan

Proceeding from the plan we outline together, you will begin background research on your project topic, with the goal of learning the language/model/analysis that is your focus. You should approach this stage with plenty of reading and experimenting with small-scale code examples. As a side effect, you will produce an exposition of the essentials of the language/model/analysis. This will become a piece of the Introduction and the bulk of the Background section of your paper (see below). We will agree on how to focus this section at our meeting and in the project outline. Also see the paper outline below. This section (and others) should include inline citations to any sources you used.

This section will grow a bit going forward, as you learn more details of your language/model/analysis while developing your project artifact. By the checkpoint, you should complete and submit an initial version of this section. Aim for about 2 pages double spaced. More detail is fine and this section will likely grow, but keep in mind that the full paper must not exceed 10 pages. (You will be surprised how quickly that approaches.

Presentation and Artifact

Next you will build a non-trivial artifact using the language/model/analysis you are exploring. Your artifact should exercise language features that set your focus language apart from languages studied in this course. You need not use all such features (in fact, understanding why you did or did not use particular features is an interesting contribution), especially if it is awkward to do so. Aim for idiomatic use of the language. In some cases, it may help to construct the same program in a familiar language for contrast. Treat this stage not just as a programming project, but as further learning about the language/model/analysis you are using. By the end of classes, you should have a first working prototype of the artifact. As you go, expand your Background section as needed with new discoveries and keep notes about the learning process and the design decisions you make. These will become the Case Study and Discussion sections of your paper (not due at this checkpoint).

On the last day of classes, your team will give a 5-8 minute presentation. (Exact time will be determined once teams have been set.) The primary goal of the presentation is to introduce your classmates to the fundamentals of the new language/model/analysis you explored. Your software artifact will serve as a means of demonstrating some of these. The artifact need not be polished by this point, but it should be at least partly working.

Final Paper

After the end of classes, you will continue work on your artifact to bring it to a working prototype state. You will also complete a paper describing the project. Details of this will vary per project, so we will tweak the plan below as needed for your team. Your Background section. should be largely complete by this time. You should focus on the Case Study section, describing your experience designing and building your artifact, and the Discussion section, analyzing the design of the tools you used. (See the outline below for more complete descriptions.) Finally, you should wrap the paper up with introduction and conclusion.

Your paper should be no more than 10 pages double-spaced in a sane font and size and should take roughly the following form, where the middle three sections all contribute significantly to the paper.

  1. Introduction. Briefly discuss:
    • the goals of the project
    • the language and specific language features you are explored
    • the program(s) you have built
    • the insights about language design you gained by using this language/feature
  2. Background. Introduce the language to an audience familiar with the concepts we learn in CS 251, focusing on the key features we identified in our project meeting.
    • Use small toy programs or other code examples to aid your discussion.
    • Use similarities to languages studied in 251 to cover familiar/expected language features briefly. Elaborate on key features that differ from the languages we know. For these features, be precise about their syntax, semantics or type-checking rules, etc.
    • If you are exploring a less directly related language (e.g., Prolog), this section will include more about the core syntax and semantics of the language.
  3. Case Study. Describe the larger program you have constructed using the language.
    • Focus on how you used (or did not use) key features of the language, referring to excerpts of your code as needed.
    • How did the language affect your high-level design and detailed implementation techniques?
    • What features were a good or poor fit for your task?
  4. Discussion. Extrapolate on your experience programming with this language and assess the design of your focus language, compared and contrasted to others previously studied.
    • Are there particular patterns or applications that are good or poor fits for the language?
    • What are the trade-offs in the design of this language? What are its particular strengths or weaknesses? How do they contrast with others studied previously? What (if anything) would you do differently if redesigning this language?
    • For each team, Ben will discuss specific features and questions to address here, tailored to the language in use.

  5. Conclusion. Briefly summarize your findings.

  6. References. Cite references consulted for your project, following ACM style.

Citations

The paper should include inline citations to any sources you used. For specific facts or results that are not common knowledge, attribute the source. When giving a general language overview, you do not need to litter the entire discussion with specific references repeatedly – you may cite them as you begin the relevant section.

Use the ACM SIGPLAN conference proceedings style for citations: all references are listed in the References section with a number. When citing something from a reference, include the number for the reference in brackets:

Static ripe-checking is a well-established technique to ensure at planting time that produce will not rot upon harvest [12].

Then in the references section:

[12] B. Wood, et al. The Barnyard of Pig Data Research. In proceedings of Potentially Computer Science, 2013.

For a more serious example, see here. A LaTeX template is available to do all of this automatically if you use LaTeX.

Installing Tools

If your project requires the installation of tools and language implementations not available on the CS department machines, please feel free to ask for assistance. (We’ll have a better chance if they are not proprietary…)