Power
Course Overview
The goal of the course is to delve deeper in to the principles of program design, implementation and understanding. We wish to help students become superb programmers who can design, implement and reason about software that is elegant, efficient, and correct, and whose code can be maintained and reused.
We use a programming language from the ML family of programming languages throughout the course: Objective Caml (OCaml). OCaml is a modern functional programming language with advanced type and module systems. However, the course is not about the OCaml language; rather, OCaml provides a convenient framework in which we can achieve the objectives of the course. Like the object-oriented model of Java, the functional paradigm of OCaml is an important programming model with which all students should be familiar, as it underlies the core of almost any high-level programming language. In addition, the OCaml type and module systems provide frameworks for ensuring code is modular, correct, re-usable, and elegant. In fact, OCaml does support objects, but we will focus more on other aspects of the language. By studying alternatives to object-oriented programming, students will be better equipped to use, implement or even design future programming environments that combine the best features of both worlds. And it turns out that once you understand how to program with functions and modules, many (most?) applications have no need for objects. Indeed, the vast majority of applications you wrote in COS 126 and COS 226 had little need of objects -- they were unnecessarily forced on you by the design of the Java programming language. OCaml is a language that allows you to choose when to use objects and when not to.
Another important reason we use OCaml is that it has a relatively clean and simple evaluation model that makes it easier to reason about the correctness of programs. In our studies, we will reason not only about the functional correctness of code, but also the space, time, and other resources used in a computation.
Finally, it is important to learn the principles of functional programming due to its connection with and use in modern, massively parallel applications in data centers. For example, Google's famous map-reduce engine, which they use to implement page rank and a variety of other applications in their data centers, has its roots in functional programming languages. We will learn more about this kind of application in the course.
Where and When
- Lectures: Monday and Wednesday, 3:00-4:20, CS 104
- Precepts:
- P01: Thursday, 10:00am, Friend 108
- P01A: Thursday, 10:00am, CS 102
- P02: Thursday, 7:30pm, Friend 109
- P03: Thursday, 7:30pm, Sherrerd 001
- P04: Thursday, 7:30pm, EQuad J201
Course Staff
If you cannot make the course staff office hours, send email (or speak to me after class) to set up an appointment.
| Name | Position | Section | Office | Hours | |
|---|---|---|---|---|---|
| David Walker | Prof | L01 | dpw@cs | CS 211 | M 4:30-5:30, W 4:30-5:30 |
| Christopher Moretti | Lecturer | P01, P02 | cmoretti@cs | CS 208 | Tu 2:30-4:00, F 1:00-2:30 |
| Ryan Beckett | Teaching Assistant | P04 | rbeckett@ | CS 242 | Tu 11:30-1:00 |
| Santiago Cuellar | Teaching Assistant | P01A | scuellar@ | CS 242 | M 1:30-3:00 |
| Jennifer Gossels | Teaching Assistant | P03 | jgossels@ | CS 313 | Su 5:00-6:30 |
Assignments
There will be seven assignments throughout the semester, approximately every one or two weeks. The last assignment will be due on Dean's Date.
Lateness policy. Programming assignments are due at 11:59pm on the date specified, with a 2-hour grace period. Late assignments are assessed a 20% penalty per day or partial day: 0-2 hours late (grace period -- no penalty), 2-24 hours late (20%), 24-48 hours late (40%), and so forth. Your penalties for the first 4 late days during the course are automatically waived. No additional lateness penalties will be waived without the recommendation of a Dean or a letter from McCosh Health Center. Do not use up your late days early!
Collaboration policy and Academic Integrity. By default, we will be using the COS 126 Collaboration Policy. You must read this policy before beginning your first assignment. If you have any questions or doubts about the policy, please ask. There is never any harm in asking for clarification of the collaboration policy. However, the penalties for plagiarism or other violations of the policy are very severe.
The COS 126 Collaboration policy refers to the "work" that you produce for the course. In COS 126, that work includes code, comments, readme files, etc. In COS 326, your work includes all those things as well as proofs of program properties. You should treat your proofs in exactly the same way as you treat your code. For example, you shouldn't show your proofs to anyone or allow them to be copied, etc.
In COS 326, you may discuss problems with friends as long as you do not share your code or proofs. In some of the assignments, we hand out some code to get you started. You can look over the (unchanged) code that we hand out with a friend in order to try to understand it. You can also discuss general strategies for solving the problems contained in an assignment, but those discussions shouldn't involve writing code together. Once you write or change a line of code, you can no longer share that piece of code with a friend. (You could re-download a fresh, unchanged copy from the course web site for a discussion, if you wanted to.)
If, for some assignment, we wish to deviate from the policies listed above, we will say so explicitly on that assignment. However, you must assume that by default there will be no deviation.
Evaluation
There will be two in-class midterms. One in the week preceeding fall break and one close to the end of the semester. Grades will be determined by weighting homeworks and midterms as follows:
- Assignments: 60% (weights among homeworks are not necessarily distributed evenly -- the longer and more challenging homeworks will be worth correspondingly more)
- Midterm I: 20%
- Midterm II: 20%