Syllabus (DCE CSCI E-51) #
Administrative information #
CSCI E-51 (Harvard Extension School course number 26029)
- Meeting times and locations
Lectures: January 26 and 28, March 9, April 20 and 27, made available online at the course web site shortly thereafter.
Labs: Distributed all other Tuesdays and Thursdays during the term for completion on-demand in small groups. This course follows the Harvard College spring calendar and thus will continue during the Extension School spring break, March 14-20. See the course calendar for details.
Code review sections: A recorded code review section from CS51 is made available, along with discussion during office hours.
- Harvard College version
The course is also offered simultaneously through Harvard College as CS51. Some course materials will be provided from the Harvard College version of the course.
Course overview #
CSCI E-51 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 CSCI E-50 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
“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 CSCI E-50; mathematical sophistication at the advanced high school level.
Extension students should complete the preparation check to ensure that this is the right course for them.
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. The labs will be made available most Tuesdays and Thursdays during the term, and students work in assigned pairs to complete the labs. Our intention is that you work on the problems in the lab together, at a convenient time for both partners. We will therefore assign partners in similar time zones where possible.
We will hold some synchronous sessions for each lab on the course discussion forum, at which students can discuss the labs with each other and with staff, and ask questions about the labs.
Lab solutions are distributed the day after the lab. Each week, lab submissions are tested in a virtual quiz.
A very small set of lectures provide background on the course and special topics. The recorded lectures will be made available through the course web site.
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. A recording of a code review section will be made available to extension students each week. Students are also encouraged to discuss each week’s lab with each other on the course forum.
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.
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.
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 will typically be held on weekends. 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.
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.
CSCI E-51 students are encouraged to discuss issues with each other and with members of the course staff using the course forum. Students will be automatically enrolled in the forum after the enrollment period has ended. Office hours and lab sessions for extension students will be held on the forum during posted times.
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 firstname.lastname@example.org.
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.
Extension students are graded separately from the FAS version of the course but are expected to meet similar standards. We recognize and appreciate and will attempt to account for the additional challenges of taking a distance course.
Approximate weightings for the course components are:
|Problem set correctness||33%|
|Problem set 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 email@example.com.
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.
Academic integrity and collaboration policy #
The course, like all courses at Harvard Extension School, operates under the salutary spirit of the Harvard Extension School policies on academic integrity. 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.
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].
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.
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 Extension School Accessibility Office (AEO) to obtain a Faculty Letter, and then contact the course administrator (firstname.lastname@example.org) 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.