There will be roughly one assignment per week. Most assignments will have a substantial programming component (covering both testing and implementation). Assignments will be graded by a combination of automated tests and live discussion of your code with course staff. More details on staff code reviews will be given once we post the second assignment.
All assignments will also have a component of peer review, in
which students write critiques of other students' work and respond to
critiques received of their own work. The reviews you write and how
you respond to others' reviews of your own work can affect your
grades, but review comments from peers will
We will use clickers once or twice a week to review course material. Clicker answers will not be graded for correctness, but clicker participation can affect your course grade.
There will be no exams.
3-Credit BS/MS Extra Assignment 2: Implementing Lists and Exceptions (due by the end of May)
Assignment 7: Calculating Names for Auto-Completion (due by 11:59pm on Monday April 2; this is a hard deadline since I want to discuss the problem a bit in the last class on Tuesday).
Assignment 6: Type Checking/Type Inference: (due Wednesday April 27 at 11:59pm). There are two options for this assignment:
Anyone seeking graduate credit or an A should do type inference.
You may opt for type checking, which is easier. If you do type checking, your maximum grade for the types assignment is a B (but you get a more manageable assignment). You don't rule out getting an A for the course if you do type-checking, but type-checking carries much less weight (so the rest of your work in the class would have to be solid (not borderline) A level to offest the lower score on types.
3-Credit BS/MS Extra Assignment 1: Haskell and Laziness (due by the last day of the term)
Assignment 5: The Essence of Objects (due Tuesday April 19 11:59pm, with extra questions for those seeking 3 graduate credits.
Assignment 4b: Second program behavior survey (in myWPI assignments area), due Tuesday April 12 before class
Assignment 4: Exploring Languages (due Monday April 11 at 11:59pm)
Assignment 3: Testing Mutation (due Monday April 4 at 11:59pm, with peer review due 24 hours later)
Assignment 2: Interpreting Functions (parts due Thursday March 24 and Monday March 28, both 11:59pm)
Assignment 1: Warming up with Racket and Peer Review (code due Friday March 18, peer review due Monday March 21, both 11:59pm)
Assignment 0: Pre-course surveys and peer-review
setup (due Thursday, March 17 before class)
When determining course grades, I will be looking for evidence that you have mastered the following four learning objectives. Sample forms of evidence for each objective are provided. Each of homeworks, peer review, and staff code reviews give opportunities for you to show evidence. You will have to show several forms of evidence to satisfy each objective.
Understand the core features that underlie most languages, including their design choices and implications
Understand how language-design choices interact with one another and affect the ability to reason about programs
Understand how to build a programming language
Produce good quality code and test suites
I will use a combination of automatic checks of your code against test suites, manual inspection of code structure, and manual inspection of the artifacts you produce during peer review when looking for evidence that you are mastering these objectives. We won't be able to read every review that you produce, but will assess your reviews on at least some of the assignments.
The D-term Elephant: This is a D-term 4000-level class, which means that some of you are simply trying to pass it so you can graduate. I appreciate this, and am not offended if "simply passing" is your goal for the course. Once assignments are underway, I will provide more information about what you need to do to "simply pass"; in particular, some of the (later) assignments will have easier options that let you demonstrate baseline understanding in exchange for a lower possible grade.
In peer review, you will be asked to provide a written evaluation of some aspect of work done by peers. We will give you some guidance on what questions to consider in writing your review, but part of the goal is to help you develop your own metrics for quality work around the course material.
Pedagogically, peer review serves several purposes:
It forces you to demonstrate your understanding of course material in a different way: you will have to detect and explain how course concepts show up in other's work.
It provides you with multiple sources of feedback on your own work, which you then have to compare and evaluate. Synthesizing different comments on your work helps you think about which aspects of the material are most important.
It gets you some early feedback on your work, often before your final deliverable on an assignment is due. This gives you time to improve your work and/or grades while you are still working on an assignment.
Peer-review has been shown to improve learning, by making students work more deeply with course material in different ways. It also teaches you a valuable, real-work job skill, as code review is a standard part of most industrial software practice.
To be clear, we are NOT using peer-review as a substitute for grading. Assessments from your peers do not affect your grade. Your failure to respond to valid comments from your peers, however, can negatively affect your grade. We will be spot-grading both the reviews that you write and how you handle feedback that you receive. These, as examples of work that you are submitting, can affect your grade.