Syllabus (FAS CS51) #
Administrative information #
CS 51 (Harvard College/GSAS course number 112960)
- Meeting times and locations
Times: All times shown are Eastern Standard Time
Lectures: January 26 and 28, March 9, April 20 and 27 at 10:30–11:45am, via Zoom.
Labs: All other Tuesdays and Thursdays during the term in one of two slots – 10:30–11:45am and 4:30–5:45pm – via Zoom.
Code review sections: Most Fridays at regular FAS course times between 8:30am and 5:45pm ET. There may be a Thursday afternoon or evening section as well.
- Extension school version
The course is also offered simultaneously through the Harvard Extension School as CSCI E-51. Extension School students should look to the CSCI E-51 web site for information about that course and refer to that website for all policies and announcements.
Course overview #
CS51 teaches fundamental concepts in the design of computer programs, emphasizing the crucial role of abstraction. The goal of the course is to give students insight into the difference between programming and programming well. One and the same problem can be solved in different ways, and the different solutions can vary along multiple dimensions including correctness, efficiency, readability, scalability, and elegance.
To emphasize the differing approaches to expressing programming solutions, you will learn to program in a variety of paradigms – including imperative (familiar from CS50 but seen here in a more elemental form), functional, and object-oriented. The elegant multi-paradigm programming language OCaml is the ideal language for manifesting these ideas. Important ideas from software engineering and models of computation will inform these different views of programming. You should come out of the course a better programmer in any language, but also a better computational thinker, with a much broader range of tools at your disposal and ability to analyze the quality of programs.
Stuart Shieber, instructor
Olivia Graham, head TF
Jordan Barkin, head TF
Ahan Malhotra, infrastructure guru
“Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.” (Antoine de Saint-Exupéry. Wind, Sand, and Stars, chapter III, translated by Lewis Galantière. New York: Reynal & Hitchcock, 1940.)
Programming ability and computer science knowledge at the level of CS50; mathematical sophistication at the advanced high school level.
FAS students in doubt about their preparation for the course may find the self-evaluation “preparation check” helpful.
Topics covered #
The following list of topics gives a sense of the subject matter of the course:
- Programming paradigms * Functional programming * First-order functional programming * Higher-order functional programming * Generic programming * Polymorphism * Data structures and types * Algebraic data types * Recursive data types * Fundamental data structures * Records, lists, trees, options, etc. * Exceptions * Modular programming * Abstract data types * Functors * Imperative programming * Reference types * Scope * Looping constructs * Lazy programming * Memoization * Streams * Object-oriented programming
- Software concepts * Formal syntax and semantics of programming languages * Backus-Naur form * Substitution semantics * Environment semantics * Complexity analysis * Big-O notation * Recurrence relations * Ethical considerations in programming * Software engineering practices * Version control * Debugging * Unit testing * Pair programming * Error handling
The primary source is a book being developed for this purpose and available for download at http://book.cs51.io. (Because the book is in active development, it is likely to change over the course of the semester. Any errors you find are gratefully received.) Required readings are listed on the course calendar.
The following books may be useful as a secondary reference. Both books are available in print and PDF form.
- John Whitington. 2013. OCaml from the Very Beginning. Cambridge: Coherent Press.
- John Whitington. 2014. More OCaml: Algorithms, Methods & Diversions. Cambridge: Coherent Press.
The following is a more complete but advanced reference. The link is to the online version available through the Harvard Library.
- Yaron Minsky, Anil Madhavapeddy, and Jason Hickey. 2013. Real World OCaml. O’Reilly Media, Inc.
Finally, the official OCaml documentation and tutorials from https://ocaml.org/ are good references as well.
Xavier Leroy, Damien Doligez, Alain Frisch, Jacques Garrigue, Didier Rémy and Jérôme Vouillon. 2018. The OCaml system release 4.07: Documentation and user’s manual. Institut National de Recherche en Informatique et en Automatique.
Coursework focuses primarily on a set of collaboratively completed labs starting the second week of classes, offered at two time slots that you will section into at the start of term. Participation in labs is strictly required, and attendance is taken. See Absences for further information.
The lab sessions begin with a short introduction, followed by pair-programming exercises to be completed in lab breakout rooms and after lab as needed. Our intention is that you work on the problems in the lab together. You should make sure that both people are working on the same problem at the same time. Don’t move on to a subsequent problem until both students understand the solution to the problem or decide together to move on. Feel free to ask for help from course staff after your pair has fully conferred on the question.
Students are randomly grouped into cohorts of four, who will rotate pairs over a series of six labs. Thus, each student is paired with each other student twice during the six labs.
After the lab session is over, you are encouraged to continue working on the lab problems individually, in your assigned pairs, or in any other groups that you see fit.
Lab solutions are distributed the day after the lab. Each week, lab submissions are tested in a virtual quiz.
For every set of six labs, during which you’ll have had the opportunity to be paired and work with each other member of the foursome twice, you will fill out a short survey to evaluate your and your partners' contributions to the lab sessions. Submitting the survey is required and is a component of your final grade.
Students with an excused absence from a lab can still access the lab materials and submit their individual submission after the lab sessions.
A very small set of lectures provide background on the course and special topics. Students are expected to attend all of the lectures that they can. The lectures will also be made available on video shortly after each lecture for review and for viewing by those unable to attend the lecture.
Chapters from the course textbook are assigned before most lectures and labs. You should complete the readings by the day before the corresponding lab or lecture. Every lab session will assume that students have done the reading for the session, and your lab partners will be relying on your having done the reading as well.
Problem sets #
A series of eight problem sets provides the opportunity to use the techniques practiced in labs on a larger scale. Each problem set typically involves the implementation of a self-contained application from a varied set of topics including game theory, symbolic math, cryptosystems, puzzle solving, music generation, and infection modeling. Early problem sets are completed individually; later ones may be done in pairs. Problem sets are typically due on Wednesdays at 11:59pm, and are submitted to the Gradescope system where they are verified for compilation. To give a sense of the amount of time students typically spent to prepare problem set submissions, the chart below shows self-reported times (in minutes; data collected for spring 2019 term).
Code review sections #
In the weekly Friday code review sections, instructional staff lead discussions of code quality in the context of class assignments. The code review sections focus on review of the lab material and solutions. Participation in your assigned code review section is strictly required.
Final project #
The final project involves implementation of an interpreter for a subset of OCaml. The final project is a more open-ended programming effort than the problem sets. You will submit both your code and a short paper describing your work.
Students who have performed especially well in class and who have an idea for a different final project topic are welcome to apply to substitute their topic. Such special projects may be done individually or in pairs.
There will be two midterm exams, one before spring recess and one at end of term. The format of the exams is still being determined, but they are likely to be open-book 90-minute exams taken within a fixed 24 hour period. Use of computers in taking the exam period is disallowed.
Coffee klatch #
I hold a very informal and optional coffee klatch on Wednesdays (January 27 through April 27, 2021 except during spring recess) from 4:30 to 5:30. These are informal meetings with up to five CS51 students. No preparation is necessary, allowed, or even possible!
You can sign up for a slot at https://url.cs51.io/coffee. Space is limited – 13 dates with 5 students each is 65 slots – allocated on a first-come, first-served basis. Please sign up for only one slot for the term, unless there are vacancies the day before the klatch.
Extra help #
We aim for the success of all students in the class and provide multiple venues for help toward that goal.
Open office hours #
We will be holding regular office hours over a suitable online platform to be determined.
Office hours are held typically on the following days: Saturdays 2-4pm and Sundays 7-9pm, Mondays 7-9pm and Tuesdays 7-11pm. The schedule appears on the course calendar.
The role of office hours is not for instructional staff to debug your code, or tell you if your code is correct, or tell you what to do to improve your code’s design or style. Rather, it is to get you making forward progress in the skills practiced in the course by helping you improve your own debugging skills, your own ability to determine if code is correct, your own intuitions about code design or style.
We’ve found that the process of recasting particular questions about code as conceptual questions about process and concepts engenders much more progress in getting your code working, and encourage you to do so.
To that end, we run two separate queues during office hours. The first queue (the “conceptual queue”) is for abstract or conceptual questions, either about the problem set or about ideas in the course. Questions are those for which no laptop is required (or allowed), for example, “I don’t understand the approach to problem x”; “I am having trouble with the idea of type signatures and type checking”; “I don’t understand how to debug my code or isolate problems with it”; or “I don’t understand the solution to one of the lab exercises”. The second queue (the “code queue”) is reserved for questions related to your code. Questions for that queue should be limited to those that require a TF to look at your laptop to view your code, and would be along the lines of: “I have a compiler error that I couldn’t debug myself” or “I have a problem with Git”. Preference is given to those in the conceptual queue by the allocation of staff primarily to that queue.
In addition, the instructor holds office hours by appointment, with Wednesdays 2-4pm especially reserved. For more information and sign-up, see https://shbr.link/contact.
Academic Resource Center #
The Academic Resource Center has tutoring help for CS51 students.
Discussion forum #
Students are encouraged to ask and help answer questions on the course discussion forum.
For individual administrative questions, please email the course’s head TFs at email@example.com.
The description below of the grading method used, complicated as it is, is provided in the interest of grading transparency. We may, however, introduce minor variations from this method of calculating final grades.
Your grade in the course will be based on your performance on the various course components – virtual quizzes, problem sets, final project, and exams – as well as your contribution to the learning of others as evidenced by your collaborations with your partners in labs including post-lab surveys, your contributions to questions and answers on the course discussion forum, and your useful contributions in code review sections, among other factors.
Approximate weightings for the course components are:
|Contributions to the learning of others||5%|
|Problem sets – correctness||33%|
|Problem sets – design/style||17%|
|First midterm exam||10%|
|Second midterm exam||15%|
Each component is calculated as the average of the z-score of each subcomponent. For instance, each problem set correctness score is standardized to a z-score and the eight z-scores are averaged to form the problem set correctness component score. (Since z-scores depend on the actual raw score distributions, they constitute a kind of curving.) We report means and standard deviations for each subcomponent so that you can get a sense of your overall score in the course.
Finally, scores are converted to grades using (provisionally) the following cutoffs.
|Grade||Minimum average z-score|
For instance, a student with an averaged score of 0.18 would receive a B+. With these cutoffs, historically approximately half of students receive an A or A– grade, and approximately half B+ or below, consistent with grading norms throughout the sciences and engineering.
Because of the collaborative nature of so much of the instruction in CS51, especially in labs, we require active engagement in those course components. If you plan to participate in academic or extra-academic activities that would regularly preclude you from attending lab, enrollment in CS51 will not be possible.
This requirement is reflected in the grading policy as well. We will reduce the final grade based on unexcused absences from labs as per the following schedule:
|Absences from||to||Half-grades deducted||Reduction from A|
Of course, absences precipitated by any health issues will be excused. Absences based on required, pre-planned participation in other academic and extracurricular activities will also be excused upon a timely request several days in advance. Requests for any of these issues should be submitted at https://url.cs51.io/absence, with corroborating information provided as soon as possible thereafter by email to firstname.lastname@example.org.
Grading anonymity and regrading #
All grading is performed double-blind: The staff do not grade problem sets and exams based on the membership of their code review sections, and are unaware of the identity of students whose work they are grading. Conversely, students are not informed of who graded their work.
All problem set regrading
is done by the head TFs and all exam regrading is done by the instructor. Regrade requests must be received within a week of the problem set or exam grades being posted. In requesting regrading, please be aware that the problem set or exam may be regraded beyond the specific issue noted and scores may move in either direction.
Grading of labs #
Participation in labs affects your grade in several ways.
Most importantly, it is through the labs that the concepts and skills are taught in the course.
Second, your participation in all aspects of the lab – preparation, attendance, collaboration with members of your group – will be reflected in the self- and peer evaluations that are used in assessing your contributions to the learning of others.
Finally, some of the lab problems are tested in “virtual quizzes”. Every Sunday, we will rerun the unit tests on the most recent submissions of the previous week’s labs. The unit tests on some of the problems, typically the first few on the lab, will constitute a virtual quiz for that lab. The percentage of unit tests that your lab passes constitutes your score on the quiz. Since the results of lab unit tests are provided to you upon every lab submission, you’ll always know how you will fare on the upcoming virtual quiz.
The virtual quizzes are intended to be low stakes assessments. In order to reduce the stress from the virtual quizzes, we will automatically drop the half of the virtual quizzes with your lowest scores.
Grading of problem sets #
Problem sets are graded based on their correctness as measured by automated testing against unit tests, as well as the quality of the solutions in terms of their design and style, including readability, maintainability, elegance, and efficiency when applicable. You will receive separate scores for correctness (on a 0–10 scale, based on the proportion of unit tests that your submission passes), and on design and style, on a scale according to the following rubric applied holistically to the submission:
|0||Essentially nothing was turned in beyond the distribution code. (0)|
|X||Something was turned in that shows some effort was taken, but indicates major conceptual problems. (0)|
|✔–||Needs improvement, showing some holes in understanding or substantive problems. (3)|
|✔||A good job, showing understanding of the concepts, and with no major problems and few minor ones. (4)|
|✔+||Exemplary; the instructors would have been proud to turn this in. (5)|
✔+s are likely to be very rare; graders typically award them to only a few percent of submissions. A student doing very well in the course should be getting mostly ✔s, with some ✔–s and perhaps an occasional ✔+. Grades in the ✔ range are thus quite respectable. Students should not expect to get many ✔+s, though striving for them is a good idea.
For the purpose of grading, the design and style score is converted to a number as per the parenthesized numbers in the table above. The design and style scores are normalized separately and averaged to form the problem set design and style component of the final grade.
Grading of final projects #
Final projects are assessed similarly to problem sets along multiple dimensions: including the correctness and design and style of the code and the content and the presentation of the accompanying paper. The score for the final project is calculated as a weighted average of these subcomponents. Late days cannot be used for the final project.
Submitting coursework #
All student solutions to programming exercises, including problem sets, labs, and the final project, should be submitted to the course grading system. Submissions by email are not accepted.
Submitting problem sets and final project #
For problem sets and the final project, the grading system automatically checks every submission to make sure that it compiles cleanly against a series of unit tests. Submissions that do not compile are rejected. Any attempt at submission that fails to compile cleanly receives a 0. Rejection is equivalent in both process and grading to not having submitted the problem set at all.
Problem set submissions that are accepted (having compiled cleanly against the unit tests) will be graded automatically against the unit tests as well as manually for their quality along the dimensions of design and style.
All problem sets are due on the indicated due date by 11:59 pm unless otherwise indicated. Occasionally, extraordinary circumstances may make it impossible for you to submit your solutions on time. For this reason, we allow for five “late days” for your problem sets. For each day a problem set is turned in late, up to two per problem set and allocated “greedily", you will be charged one of your allotted late days. For example, if a problem set is due on Wednesday at 11:59 pm it can be turned in by 11:59 pm on Thursday charging one late day, or by 11:59pm Friday charging two, but will receive no credit thereafter. Late days are measured only in full days (not in hours). After two days, we will not accept late homework and will stop charging late days; that is, only two late days will be charged for unsubmitted work or work submitted exceptionally late. If you turn in a problem set late without sufficient late days remaining, the problem set will not earn any credit. However, we recommend that you turn in such problem sets anyway as we may consider them in allocating final grades in borderline cases.
For problem sets that are submitted in pairs, both partners will be charged the corresponding late days (and must therefore have sufficient late days remaining).
Submitting labs #
Lab exercises may be individually submitted at any time after the start of the lab, including multiple times, but should be submitted at least once by the day after the lab itself. Each time you submit the lab, if your submission compiles cleanly, you will receive a report of performance against the unit tests immediately upon submission, including a calculation of how well that submission would fare on the upcoming virtual quiz. There is no expectation that you finish all of the questions during the lab slot itself, although generally students get a good start on the lab work during the lab session.
For the purpose of virtual quiz grading, we will use the most recent submission before the running of the virtual quiz, which is no earlier than 11:59pm on the Sunday following the lab. You are encouraged to continue to submit labs even after the virtual quiz in order to improve your understanding of the lab material.
Course policies #
Video conferencing policies #
Because participation in video-conference interactions will be so crucial to the remainder of the course, we provide some information here on expected behavior and conventions for video-conference sessions:
Please remember that class meetings on Zoom are class meetings; they should be treated as if you were attending class on campus. This includes behaving professionally, treating others with courtesy and respect, refraining from using profanity or socially offensive language, and wearing appropriate clothing and avoiding inappropriate surroundings.
Join the meeting on time. Ideally, launch Zoom five or ten minutes early to get the audio and video set up properly.
Use a camera and microphone when attending all Zoom meetings. Mute your microphone if you’re not speaking, but leave your video on throughout meetings so others can follow nonverbal cues, especially in breakout rooms.
Join from a suitable, quiet, well-lit location, with a device that permits full participation in the class activities. In particular, do not join a class while driving or riding in a car.
Refrain from adding wacky backgrounds and video backgrounds to your video feed. If you’d like to obscure your background, using a plain background is best.
Video recording policies #
The Harvard Extension School provides the following policy for recording class sessions:
This course is being offered online using Zoom web conferencing software and the class sessions will be recorded. The Zoom recordings will be made available to students in this course and also to those in a companion Harvard Extension School course. Joining a Zoom meeting is functionally equivalent to walking into a classroom, and we want you to be able to interact with your instructors and fellow students as if you were in a classroom. For that reason, it is good to use your camera when participating in the Zoom class sessions.
If you have concerns about sharing your image or real name with the Harvard Extension School students, you must contact your instructor to make other arrangements (for example, selecting audio-only participation and displaying a pseudonymous username in Zoom).
If you use your camera and real name, you authorize Harvard to share your image and name in the recordings with the companion Harvard Extension School course, along with what you say.
Academic integrity and collaboration policy #
The course, like all courses at Harvard College, operates under the salutary spirit of the Harvard College Honor Code. That spirit is especially important in considering collaboration on course work. Students are encouraged to discuss all aspects of the course work – readings, labs, problem sets, final projects – with each other; talking together can be a useful method for working out difficulties in solving the problems and in improving your understanding of the concepts. Indeed, we will provide opportunities for this kind of interaction in the weekly code review sections and office hours.
However, except where explicitly stated otherwise, all assignments should be completed individually. By this we mean:
It is allowed and encouraged to have high-level discussions with others, but working together one-on-one directly on developing your solutions goes beyond such high-level discussions, as does sharing code (no matter how small a snippet). Such modes of “collaboration” are expressly disallowed.
Making use of others’ code that you come across is not appropriate, even if cited. Other people’s solutions to these problems may exist on the web, or in the files of past students, or on roommates' laptops, or in the recycling bin near your house printer. It is not advisable to be reconnoitering for them for help. It ought to go without saying that all individually submitted code should be the student’s own. But we said it anyway.
For problem sets and labs completed in pairs, members of the pair will of course work closely together to develop a single coded solution. But the same rules apply to members of the pair looking outside the pair for help. High-level discussion is fine; sharing code is not.
It is inappropriate, and considered a violation of the collaboration policy, to publicly post or privately distribute your coursework, including your solutions to labs, problem sets, exams, and the final project.
Collaboration is expressly disallowed on exams.
Please see the section on Plagiarism and Collaboration in the Handbook for Students for further clarification.
We actively check for violations of this policy using software to compare student work against each other and a database of past solutions and solutions available on the web. Sadly, we regularly send cases of academic integrity violations to the Honor Council, leading to students being required to withdraw from the College. We urge you not to press your luck in this area. If in doubt about where the line is between appropriate discussion and undue collaboration or appropriation of others’ work, or if you fear that you have crossed the line, you should talk to Professor Shieber immediately.
Auditing policy #
Auditors are more than welcome to attend lectures or view the lecture videos online and work on the lab materials and problem sets (which are posted on the course web site as the course progresses). However, participation in the lab sessions, code review sections, discussion forums, exams, and course office hours is restricted to enrolled students.
Simultaneous enrollment policy #
Students in CS51 are required to section into and attend one of the two lab slots. Ordinarily, you may not enroll in courses that meet at the same time or overlapping times, as described in the Harvard College Handbook for Students. If you can attend either of the lab slots, there should be no need for you to petition for simultaneous enrollment. (The small number of lectures in the course are not tracked by the registrar and overlap with them should not invoke a requirement to petition for simultaneous enrollment.)
Because attendance at lab is required, if you have conflicts with both lab slots, you will not be able to enroll in CS51 without a petition for simultaneous enrollment and an agreement from the instructor of the conflicting course that you will be attending CS51 labs and will therefore not be attending the conflicting sessions in the other course. In that case, you may petition to simultaneously enroll in CS51 and the other course under the following conditions:
You are able to attend one of the two lab slots in its entirety, you section into that slot, and you agree to attend labs rather than the conflicting sessions of the other course.
You are able to attend one of the many code review time slots in its entirety, and you section into that slot.
You are able to attend both evening midterms in their entirety. (See the course calendar for dates and times.)
You are able to watch the lecture videos for any missed lectures in a timely fashion and commit to do so.
The instructor in the conflicting course agrees to this arrangement.
If you can commit to these conditions, the Administrative Board will consider petitions for simultaneous enrollment. Contact the course administrator (email@example.com), who can provide the required statement for petitioning the Administrative Board.
Late enrollment policy #
Because the course ramps up quickly through collaborative activities, it is difficult to join the course late. We therefore strongly recommend against joining the course after the second week, and will under no circumstances approve joining the course after the third week. Keep in mind also that labs begin the second week of the course, so that joining the course late will lead to missed labs, with the concomitant effect on the final grade as described in [the section on absences][Absences].
Pass/fail policy #
CS51 can be taken pass/fail with the following proviso: Because the course relies so much on collaborative effort in labs, all students, including those enrolled pass/fail, are under a moral obligation to the others in the class to participate fully in labs and all its associated processes, including preparation for lab (especially doing the reading before lab), lab attendance, engagement during lab, submission of labs, and the post-lab surveys. Thus, taking the course pass/fail is unlikely to provide much time relief in the course, though it may reduce grade anxiety. Students interested in taking the course pass/fail should contact the course administrator (firstname.lastname@example.org) well before the pass/fail deadline (fifth Monday of term).
Course climate #
It is my intention to have a course climate that is open to and inclusive of everyone – of all races, genders, sexual orientations, ethnicities. You may think that the subject matter of this course doesn’t lend itself to interactions of exclusion or mean-spiritedness. Unfortunately, you would be wrong; I have already seen and acted upon incidents of just this sort in the course.
The preventative for these kinds of interactions is empathy. I urge all participants in the course – staff and students – to think empathetically as we all interact with each other. Because I strive to be a moral person, I attempt to be empathetic myself. But I know that even the best of intentions can inadvertently fail. If you find any of my own behaviors to infringe on the open climate I strive for, please let me know, either directly or through a friend, so I can benefit from the event and improve my own behavior. If you would prefer to go through an independent, neutral, and confidential service, the Harvard University Ombudsman Office can serve as intermediary.
Mental health #
If you experience significant stress or worry, changes in mood, or problems eating or sleeping this semester, whether because of CS51 or other courses or factors, please do not hesitate to reach out immediately, at any hour, to any of the course’s heads to discuss. Everyone can benefit from support during challenging times. Not only are we happy to listen and make accommodations with deadlines as needed, we can also refer you to additional support structures on campus, including, but not limited to, the below.
Accommodations for students with special requirements #
We will happily accommodate any student with special requirements. Students needing academic adjustments or accommodations because of a documented disability should contact the FAS Accessible Education Office (AEO) to obtain a Faculty Letter, and then contact the course administrator (email@example.com) by the end of the second week of the term. Failure to do so may result in our inability to respond in a timely manner. All discussions will remain confidential.