CS164, Fall 2006: Course Information

These pages are under construction. There will be a lot more here later.

Personnel

Name Room Phone E-mail Hours
Instructor: Paul N. Hilfinger 787 Soda Hall 642-8401 Hilfinger@cs.berkeley.edu, cs164@cs TBD
TA: Brendan Clark TBD 751 Soda (office hours only) bjclark@berkeley.edu Thurs 4-5, Fri 12-1

Purpose of this Course

CS164 is an introduction to the design of programming languages and the implementation of translators for them. In the process, we'll do some general exploration of programming language design and its implications for implementation, and look at a dialect of at least one particular language, which this semester is Python.

One goal of this course is to explore the structure of programming languages and to consider alternatives to familiar programming language features. We'll also study the problem of translating programming languages into machine-executable forms, using Python as a concrete example of a language to be translated, and the assembly language of the Intel ia32 family (used in PCs and some of our Solaris workstations downstairs) as a concrete example of a target machine. We study language translation first to learn some of techniques used that are useful for many programming problems outside of language translation, second to gain a better intuitive feel for the tools we use when programming and the costs of the programs we write, and third (possibly most important) to gain experience with the engineering problems associated with building and validating a substantial piece of software.

Prerequisites

Please do not take this course unless you have the prerequisites: CS61B and CS61C, or equivalent courses (at a junior college, for example). You should be familiar with Java or C++. You need not be familiar with Python.

Reference Material

There is no required textbook for this course, since none is altogether satisfactory. Officially, we'll rely on notes that I provide (on paper and on the web), but many people feel more comfortable if they can supplement this information with other treatments. You might want to take a look at the following books:

Course Work

The major work in the course consists of building a system to translate programs written in Pyth, a dialect of Python, a popular scripting language. The system will be divided into modules, with each module constituting an assignment. The implementation language is C++ or Java. In addition to the project, there will be a midterm, a final examination, and some ordinary written homework.

Collaboration

You may work on the various modules individually or in pairs, but I encourage you to work in pairs. Collaborating with someone often encourages more attention to your programming technique and gives you practice in one of the "real-world" social aspects of computing that university courses must generally ignore. As an extra bonus, working in pairs substantially reduces the strain on our computing resources. Each pair will submit one module and each member of the pair will receive the same grade for that module. The exams may contain questions about the modules, so it is extremely unwise to allow your partner to do all the work. Although the Staff (elsewhere known as "we") will be happy to give advice, it is the responsibility of partnerships to work out their own disputes. Partnerships apply only to the project assignments, not to tests or other written homework. Students taking the course Pass/Fail may not take graded students as partners. Groups of more than two people will not be allowed except with my explicit consent.

I encourage collaboration among groups, as long as it is restricted to questions of strategy as opposed to actual program text. Each partnership or individual is responsible for making it clear that their work is really theirs. Except for general-purpose utilities (e.g., a doubly-linked list package) you should not generally borrow other people's code. For anything you do borrow (including ideas) you must give proper credit in comments. Naturally, over-dependence on others' ideas will adversely affect your grade on a module, but failure to give credit where credit is due falls under the heading of "cheating."

Cheating (also known as plagiarism) is the presentation of someone else's work as your own. It will not be tolerated. Violators will fail the course and will be reported to the appropriate disciplinary agency. It is not possible for only one member of a partnership to cheat on a project assignment; any transgressions on your part will reflect equally on your partner.

Grading

In an attempt to cut down on cutthroat competitiveness and to make your grade a bit more meaningful, I use an absolute grading scale. Your letter grade will be determined by the total number of points on all assignments: A for 170–200 points, B for 140–170, C for 110–140, and D for 80–110, with plusses and minuses awarded to the top and bottom third of each grade. These divisions are based on past classes' performances. Out of the total 200 points, the final counts for 55, the midterm for 35, and other written homework and project assignments total 110.

Ordinary homework doesn't get many points, because I see it mostly as a chance for exercise. You will be given full credit for handing in a solution in which you demonstrate that you have made a substantial effort on each problem. Since solutions will be available after the due date, late homework won't be graded.

Unless otherwise indicated, you should hand in all assignments electronically by the deadline given on the assignment. I'll penalize an assignment $5 N/12$ percent for each $N$ hours it is late, rounded off in some unspecified fashion. During the course of the semester, however, we'll give you a total of three late days (72 hours) for free. You may, for example, turn in all but one assignment on time and turn the other in three days late, or you may turn in each of three assignments one day late. Needless to say, you are not obliged to turn in any of them late, and it is advisable never to be more than one day late.


Page was last modified on Mon Dec 11 02:49:18 2006.
Address comments and questions to cs164@cs.berkeley.edu