Course Syllabus

Jump to Today

Administrative information

Course

CS 51 (Harvard College/GSAS course number 112960)

Term

Spring 2017–18

Location

Lectures in Science Center B, at the nonstandard time of 2:30pm–4:00pm, for the first week only (January 23 and 25), and thereafter Maxwell Dworkin G115. Labs and office hours held in Northwest Building ground floor.

Meeting times

Lectures: Tuesdays (and some Thursdays) 1:00pm–2:30pm
Labs: Thursdays 11:30am–1:00pm; 1:00p–2:30pm; 2:30pm–4:00pm
Code review sections: Fridays hourly 9:00am–5:00pm

Instructor

Stuart M. Shieber

Course description

Abstraction and design in computation. Topics include functional and object-oriented styles of programming, software engineering in the small, and models of computation. Our main goal is to understand how to design large programs to make them readable, maintainable, elegant, and efficient.

Extension school version

The course is also offered 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 programming, 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 – 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.

Staff

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 CS50; mathematical sophistication at the advanced high school level.

FAS students in doubt about their preparation for the course may find the CSCI E-51 preparation check of interest. It is available in PDF form on Canvas, under Files > Handouts.

Website

http://cs51.io

Required texts

The primary textbooks are

Both books are available in print and PDF form, though only the print form (or printed selections from the PDF) can be brought into the course exams. See the section on Exams below.

In addition, course handouts will be made available on the course web site.

The following book may be useful as a secondary 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.

Coursework

Lectures

There are roughly weekly lectures, on Tuesdays and occasional Thursdays (when there is no lab), covering the conceptual aspects of the course. Lectures are recorded and videos and slides are made available online some time after each lecture.

Labs

Labs are held on most Thursdays, in place of lecture, at three time slots (11:30-1, 1-2:30, 2:30-4, as sectioned at the start of term). The lab sessions involve a short introduction, followed by pair-programming exercises to be completed in lab and thereafter. Attendance at labs is required.

Upon arrival at lab, you will be randomly assigned to a “table for two” to work in pairs. 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 pass. Feel free to ask for help at any time, but only after your pair has conferred on the question. 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.

After each lab session, you will be emailed a short survey to rate your own understanding of the material as well as your partner’s. This is for research purposes only. Submitting the survey is required and part of your grade for the lab, in addition to submitting the lab code itself.

Students unable to attend their lab slot may on occasion attend an alternate slot. Students unable to attend any lab slot one week can submit the exercises after the lab sessions when the exercises are posted to the course web site.

Readings

Short readings are assigned before most lectures and labs. Every lecture and lab session will assume that students have done the reading for the session.

Surveys

A survey with questions about the reading is to be filled out by midnight the night before the corresponding lecture or lab.

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 will frequently focus on review of the lab material and solutions. Students are required to attend their assigned code review section.

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. Students submit both their code and a short paper describing their 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 midterms, one before spring recess and one at end of term. The exams will take place in the evening. Please reference the Course Calendar for their timing.

Notes and books may be used in the exams, but not electronic devices. Some students choose to purchase the print copies of the textbooks for this reason, though the exams are designed in such a way that access to books should not be needed.

Extra help

We aim for the success of all students in the class and provide multiple venues for help toward that goal.

Office hours

Regular office hours are held in the Northwest Building ground floor, typically on Monday and Tuesday evenings. The schedule appears on the course’s Canvas 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. It is to get you making forward progress in the skills practiced in the course by helping you improve your own debugging skills, your ability to determine if code is correct, your 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.

Bureau of Study Counsel

The Bureau of Study Counsel has tutoring help for CS51 students.

Discussion forum

Students are encouraged to ask and help answer questions on the course Piazza discussion forum.

For individual administrative questions, please email the course’s Head TFs at cs51heads@gmail.com.

Grading

Your grade in the course will be based on your performance on the problem sets, final project, and exams, as well as your submission of labs and surveys, and your contribution to the learning of others (as evidenced by your contributions to questions and answers on Piazza and your useful contributions in code review sections).

Approximate weightings for the course components are:

Component Percentage
Labs, surveys, code review, learning of others 10%
Problem sets 50%
Final project 15%
First midterm exam 10%
Second midterm exam 15%
Total 100%

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. 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 and surveys

Labs and surveys are graded solely on timely submission, not result.

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 number of unit tests that your submission passes), and on design and style, each on a 0-5 scale according to the following rubric applied holistically to the submission:

Score Meaning
0 Nothing was turned in.
1 Something was turned in that shows some effort was taken, but is otherwise wholly inadequate.
2 The solution is poor, showing major holes in understanding.
3 The solution is adequate, but shows occasional misunderstandings or errors.
4 A good job, with no major problems and few minor ones.
5 Perfection; the instructors would have been proud to turn this in.

5s 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 4s, with some 3s and perhaps an occasional 5. Grades in the 3–4 range are thus quite respectable. Students should not expect to get many 5s, though striving for them is a good idea.

We use this approach in order to maximize the dynamic range in the design and style scores, so that there is maximal information provided for the grading. The wrong way to interpret these grades is on a linear absolute scale. That is, a 4 does not correspond to an 80% to be blindly interpreted on an arbitrary scale of 90+ = A, 80+ = B, etc. Rather, these grades are normalized and aggregated at the end of term using a formula that takes into account many factors including relative difficulty of the problem set and expectations of performance at course stage to generate a score that encapsulates how each student fared. That score is converted to a final grade reflecting current letter grading norms across the college. In the past, the mean grade in the course has been an A–/B+.

Because of this normalization, calculating a single “grade” for each problem set is not possible out of context. In particular, please note that merely adding up the three component numbers is a meaningless arithmetic operation.

Grading of final projects

Final projects are assessed similarly to problem sets along multiple dimensions: including the correctness, design, and style of the code and the content and presentation of the accompanying paper.

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 under any circumstances.

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. You will receive a report of performance on the unit tests once the problem set is fully graded.

All problem sets are due on the indicated due date by 5:00 pm EST unless otherwise indicated. Occasionally, extraordinary circumstances may make it impossible for you to submit your solutions on time. For this reason, we provide 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 5:00 pm, it can be turned in by 5:00 pm on Thursday charging one late day, or by 5:00 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).

Submitting labs

All lab exercises are due on the day of the lab by 11:59 pm EST of that day, although a good start on the lab work will generally be completed during the lab session itself.

Lab submissions receive full credit upon timely submission regardless of their performance against the unit tests, or even whether they compile against the unit tests. You will thus want to submit the lab at least once on the day of the lab itself. Nonetheless, you should make every effort to complete the labs in their entirety, early, and often.

If your lab submission compiles cleanly, you will receive an immediate report of performance against the unit tests immediately upon submission. There are no late days for labs, though you are welcome to submit the labs multiple times including on days after the lab to receive further unit testing results for your solutions to the individual exercises.

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, as there is limited availability of power outlets.

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 (currently sporting these wireless beauties), 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.

However, except where explicitly stated otherwise, all assignments should be completed individually. By this we mean:

  • It is fine 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 rommmates’ 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 work 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.

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

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. However, you may petition to enroll in CS51 and another course whose meetings overlap fully or partially with the CS51 Tuesday 1-2:30 time slot under the following conditions:

  1. You are able to attend one of the three Thursday lab slots (11:30-1, 1-2:30, 2:30-4) in its entirety, and you section into that slot.

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

  3. You are able to watch the lecture videos for any missed classes in a timely fashion.

If you can commit to these conditions, and the other course agrees to the simultaneous enrollment, the Administrative Board will consider petitions for simultaneous enrollment. Contact Alessandra DeLucas (adelucas@g.harvard.edu), who can provide the required statement for petitioning the Administrative Board.

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 Alessandra DeLucas (adelucas@g.harvard.edu) 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.

Course Summary:

Date Details Due