|Paul N. Hilfinger|
|787 Soda Hall|
|Email: Hilfinger@cs.berkeley.edu, cs164@cs|
|Office Hours: TBA|
|Office hours: Tu 10 AM - 12 PM, Soda 611|
|Office Hours: Fri 12 PM - 2 PM, South Hall|
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 alternative forms, including ones that are machine-executable, using Python as a concrete example of a language to be translated, and such things as the assembly language of the Intel ia32 family (used in PCs), or the C language as concrete examples of a translation target. 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.
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++.
There is no required textbook for this course, since none is altogether satisfactory, and all tend to be ridiculously expensive. 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:
The major work in the course consists of building a system that involves programming-language translation. The system will be divided into modules, with each module constituting an assignment. In addition to the project, there will be in-class tests, a final examination, and some ordinary written homework. I do not recommend taking this course P/NP. In general, I find that students tend to give their P/NP lower priority than their graded courses, and this is not, perhaps, such a good thing when a lot of the benefit one gets from the course is from the (intensive) project work, and especially when one is working on a team,.
I encourage collaboration among teams, 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.
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 160–200 points, B for 130–160, C for 100–130, and D for 75–100, with plusses and minuses awarded to (roughly) 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 50, the two additional tests for 20 apiece, 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. For the first 24 hours late, I'll penalize a project 5% of the maximum score, prorated hourly, rounded off in some unspecified fashion. The penalty rises to 10% after that, and no submission will be accepted after 72 hours. In general, it is the final submission (or partial submission) of something that counts, so making a change one day after a deadline is one day late. We will may forgive lateness for trivial changes, and we can ignore inadvertant late submissions entirely. Your best procedure, if you want to make a small change in an assignment and aren't sure whether we'll let you do it without lateness penalty, is to submit the change and then ask us. We can always undo a submission if it turns out to have been the wrong thing to do. Students with DSP accommodations are sometimes given extensions for ordinary homework assignments. However, because our projects are team efforts, we cannot give such accommodations on projects, since they are not individual efforts.
Page was last modified on Fri Jan 11 15:31:53 2019.