Abstraction and Design in Computation
Abstraction and Design in Computation
Harvard Extension School: 24816
Note: A one-time Lab1 session for extension students will be held on Friday, Feb 3 from 2:30pm - 4:00pm (EST). All other labs will be held on Thursdays.
|Type||Day||Time (all times EST)||Location|
|Lecture||Tuesdays (and some Thursdays)||1:00pm - 2:30pm||Lecture Videos (from DCE)|
|Labs||Thurdays*||11:30am - 1:00pm||Slack (#labN)|
|Code Review Sections||Fridays||by end of day||Posted online from FAS|
|Office Hours||Sundays, Mondays, Wednesdays||Detailed schedule here||Slack (#general)|
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.
CSCI E-51 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, but also a better computational thinker, with a much broader range of tools at your disposal and ability to analyze the quality of programs.
"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 / 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.
The primary textbooks are
- John Whitington. 2013. OCaml from the Very Beginning. Cambridge: Coherent Press.
- John Whitington. 2014. More OCaml: Algorithms, Methods & Diversions. Cambridge: Coherent Press.
Both books are available in print and PDF form.
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.
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
A fundamental component of the course is the completion of lab exercises. Students are encouraged to form small groups to work together on labs. There will also be lab-related sessions with the teaching staff on Slack.
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.
- 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 Slack.
- 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.
There will be two midterms, one before spring recess and one at end of term. Please reference the Course Calendar for their timing. These exams are administered as proctored exams as per DCE rules. Extension students are expected to handle the logistics of exam scheduling and should consult the DCE examinations office for further logistical information.
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 will be held on Slack, typically on weekends. 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.
CSCI E-51 students are encouraged to chat with each other and with members of the course staff using Slack. Students will be automatically enrolled in the Slack group after the enrollment period has ended. Office hours and labs sessions for extension students will be held on Slack during posted times.
- 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 firstname.lastname@example.org.
Your grading 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. Extension students are graded separately from the FAS version of the course but are expected to meet similar standards. We recognize and appreciate the additional challenges of taking a distance course.
Labs and reading surveys are graded on timely submission, not result.
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 (based on the number of unit tests that your submission passes), and on design and style (each on a 0-5 scale). These separate components of the overall problem set evaluation are eventually combined using a formula that takes into account many factors including relative difficulty of the problem set and expectations of performance at course stage. Thus, 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 an entirely meaningless arithmetic operation. In particular, doing so grossly underweights the design and style scores. (A better approximation of the weighting of correctness:design:style has generally been 2:1:1.)
Final projects are graded on the quality of both the writeup and the code along all pertinent dimensions.
Approximate weightings for the course components are:
|First midterm exam||10%|
|Second midterm exam||15%|
All student solutions to programming exercises, including problem sets, labs, and the final project, should be submitted to the course grading system. Solutions by email are not accepted under any circumstances.
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 multiple dimensions of design and style. You will receive a report of performance on the unit tests once the problem set is fully graded.
Lab submissions receive full credit upon timely submission regardless of their performance against the unit tests. You will receive a report of performance against the unit tests immediately upon submission and may resubmit as many times as you like. Timely submission is all that is required to receive full credit.
All problem sets are due on the indicated due date by 5:00 p.m. 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 p.m., it can be turned in by 5:00 p.m. on Thursday charging one late day, or by 5:00 p.m. 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).
All lab exercises are due on the day of the lab by 11:59 pm of that day, although we expect that much of the lab work will generally be completed during the lab session itself. Labs are graded on timely submission, not results, so you will want to submit the lab at least once on the day of the lab itself. 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.
Academic integrity and collaboration policy
The course, like all courses at Harvard College, 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.
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 in Science Center wastebaskets. It is not advisable to be looking 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.
If in doubt about where the line is between appropriate discussion and undue collaboration or appropriation of others’ work, please talk to a member of the instructional staff.
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.
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 speak with one of the instructors 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.
The syllabus page shows a table-oriented view of the course schedule, and the basics of course grading. You can add any other comments, notes, or thoughts you have about the course structure, course policies or anything else.
To add some comments, click the "Edit" link at the top.