Syllabus (FAS CS51) #

Administrative information #

Course

CS 51 (Harvard College/GSAS course number 112960)

Term

Spring 2024

Meeting times and locations

Times: All times shown are Eastern Standard Time

Lectures: 12:45-2:00pm on January 23, January 25, April 18, and April 23, 2024, in the SEC building, Room 1.321.

Labs: All other Tuesdays and Thursdays during the term in one of two slots (12:45–2pm and 3:45–5pm) in 114 Western Ave, Room 2112.

Code review sections: Most Fridays at regular FAS course times between 8:30am and 5:45pm. There may be a small number of Thursday afternoon or evening sections as well.

Exams: Provisionally scheduled for March 4 and April 24.

Instructors

Stuart M. Shieber

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.

College concentration requirements #

CS 51 satisfies the Programming 2 requirement for the computer science concentration, and may be used as one of the four CS courses to satisfy the requirements for a secondary field in computer science. The full set of tags for the course are available here.

Staff #

• Stuart Shieber, instructor

• Lauren Kwee, head TF

• Gerson Personnat, head TF

• Jayden Personnat, head TF

• Nicole Chen, Patel Fellow

Philosophy #

“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.)

Playlist #

Available here.

Prerequisites #

Programming ability and computer science knowledge at the level of CS32 or CS50; mathematical sophistication at the advanced high school level.

Students in doubt about their preparation for the course may find the self-evaluation “preparation check” helpful.

Website #

http://cs51.io

Calendar #

See here for the full calendar.

Coursework #

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

Texts #

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.14: Documentation and user’s manual. Institut National de Recherche en Informatique et en Automatique.

• OCaml Tutorials.

Labs #

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.

You must attend your assigned lab slot. If you cannot attend a particular lab in your registered slot, you should not show up for the other slot. Rather, you’ll need to handle this as an absence, ideally excused. See the policy on excused absences. If you want to switch permanently into a different slot within the first two weeks of the course, please contact course staff. After the first two weeks of the course, switching lab slots will not be allowed.

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 about fifteen, who will work together in randomly assigned pairs over a series of 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.

Students with an excused absence from a lab can still access the lab materials and submit their individual submission after the lab sessions.

Lectures #

A very small set of lectures provide background on the course and special topics. Lectures are not optional. Students are expected to attend all of the lectures that they can. That said, if you are in the 3:45 lab slot and have a class that regularly conflicts with the 12:45 lectures, your grade will not be lowered if you are unable to attend the lectures. (No need to notify us; we will assume you have a valid excuse.) 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.

Readings #

Chapters from the course textbook are assigned before most lectures and labs. You should complete the readings and the corresponding reading survey (submitted via Canvas) by 11:59 pm 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.

We will drop up to 5 missed reading surveys.

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:59 pm, 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.

Exams #

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, closed-internet, proctored 90-minute exams.

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 at a location to be determined.

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.

In addition, the instructor holds office hours by appointment and during regularly scheduled office hours. For more information and sign-up, see https://shbr.link/contact.

Academic Resource Center #

The Academic Resource Center has peer tutoring help for CS51 students. We have found peer tutoring to be especially helpful early in the semester, so students are encouraged to make use of peer tutoring earlier rather than later.

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 heads@cs51.io.

Grading #

The description below of the grading method used, complicated as it is, is provided in the interest of grading transparency. We may, however, introduce variations from this method of calculating final grades. Such variations will not be major.

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 during the lab, 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:

Absences #

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:

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. Requests for any of these issues should be submitted at https://url.cs51.io/absence. We will reach out, typically within 48 hours of your form submission, if there are any issues with your request.

For absences due to isolation for COVID-19-related reasons, please see the policy on COVID-19/Isolation.

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 quarter of the virtual quizzes (5 of the 20) 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:

✔+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. Although Gradescope also reports an unweighted sum of these two scores, the sum is not used directly. The design and style scores are normalized separately from the correctness score 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 eight “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:59 pm 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).

There is no need to contact course staff about late days; they are automatically tracked by Gradescope.

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:59 pm 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 #

Laptop policies #

Students are kindly requested not to use laptops or other screen devices during lecture.

Laptops are required for labs. Please make sure that you have ample charge in your battery for lab sessions.

If you require a computer for the class, loaners are available through SEAS Computing which has a small number of loaner computers available to students to use for a couple weeks at a time. These loaner computers are only a temporary solution though, so you’ll need to work on repairing or replacing your current machine. Please email ithelp@harvard.edu to arrange.

Headphone policy #

It should go without saying that headphones are not appropriate for use during any class activities, including lecture and lab. It should go without saying, yet we say it, because we have had students running afoul of common sense in this area. The instructor is as big a fan of headphones as anyone, but using these or any other sound-excluding device during lecture and lab is just not the thing.

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. Others’ 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. What counts as “others’ solutions” includes answers written by previous or current students in the course; answers posted on programming forums such as StackOverflow, whether in response to your query or others’; and answers generated by software systems such as ChatGPT or Copilot. 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 course materials, including the labs, problem sets, and course lab solutions, and your own 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 speak to the instructor immediately.

Auditing policy #

Auditors are more than welcome to attend lectures or view the lecture videos online, make use of the course textbook, 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:

1. You are able to attend one of the two lab slots in its entirety, you section into that slot, and you agree to attend all labs rather than the conflicting sessions of the other course.

2. You are able to attend one of the many code review time slots in its entirety, and you section into that slot.

3. You are able to attend both midterms in their entirety. (See the course calendar for dates and times.)

4. You are able to watch the lecture videos for any missed lectures in a timely fashion and commit to do so.

5. 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 (administrator@cs51.io), 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 first week, and will under no circumstances approve joining the course after the second week. Therefore, if you are unsure whether you want to enroll in the class, we recommend that you enroll, attend, and keep up with coursework from the start, and drop the course before the third Monday of term.

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.

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, and submission of labs. 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 (administrator@cs51.io) well before the pass/fail deadline (fifth Monday of term).

Course climate #

It is our 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; we have already seen and acted upon incidents of just this sort in the course.

The preventative for these kinds of interactions is empathy. We urge all participants in the course – staff and students – to think empathetically as we all interact with each other. If there is anything in the course – including the actions or behavior of the instructors or other course staff – that infringes on the open climate that we strive for, please let one of the instructors or head TFs know, either directly or through a friend, so that we can work to improve. 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 Ombuds Office can serve as intermediary.

COVID-19/Isolation policies #

If you are in isolation, you can inform the course heads by filling out the form at https://url.cs51.io/absence. This is all you need to do in order to be excused from attendance at any labs and code reviews that occur while you are in isolation.

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.

• Counseling and Mental Health Services, 617-495-2042
• Room 13, 617-366-7375

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 Disability Access Office (AEO) to obtain a Faculty Letter, and then contact the course administrator (administrator@cs51.io) 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.