Princeton University
Computer Science Dept.

Computer Science 333:
Advanced Programming Techniques

Spring 2001

Brian Kernighan
Mon May 14 15:16:30 EDT 2001

A couple of people have asked about installation and other aspects of project submission.

We are most interested in having access to a working version of the system so we can play with it; that's important. You might find it useful to ask a friend to try it from a machine in the CS department and make sure there isn't some obvious problem; after that, you should be ok. If something does come up, we'll just send you mail and let you straighten it out.

The installation part is mostly to make sure that all the files are included and there's enough of a roadmap that someone really dedicated (not me) could get it installed on a new system; it's partly a way to encourage you to be sure that you've included everything that's needed. For instance, can you take your own installation package and move it to another machine and install it yourself as if you were a new developer? That's almost always a good check, and if that works, it should be fine for us too.

Newsgroup

Lecture notes: 2/6-8    2/12    2/12-14    2/14    2/22    2/27    3/1    3/6-8    3/13    3/15    3/27    3/29    4/3-10    4/12    4/19    4/26    5/1    5/3   

Project: 2/20 Overheads     Preliminary description (2/19)     TA assignments     Second project handout (3/27)     Carl Kingsford's CVS slides     Third project handout (4/16)     Fourth project handout (5/1)    

Assignments: 1     2     3     4     5

Reading:
4/5: Dennis Ritchie's slides
4/3: Visual Basic resources page; also check out Lab4 and Lab5 in COS109.
3/29: Plumbing code of various sorts
3/21: Networking info from The Pocket Guide to TCP/IP Sockets
3/13: STL description if you would like more details.
2/27: Languages as their inventors see them: Dennis Ritchie (C), Bjarne Stroustrup (C++), James Gosling (Java), and Larry Wall (Perl).
2/8: Programming for the 21st Century, by John Ousterhout.

Old stuff: gdb summary     Survey     ed to grep assignment

 

Course Summary

The 2001 version of this course will be similar to the Spring 2000 version.

This is a course about the practice of programming, an attempt to expose students to the development of real programs. Programming is more than just writing code. Programmers must also assess tradeoffs, choose among design alternatives, debug and test, improve performance, and maintain software written by themselves and others. At the same time, they must be concerned with compatibility, robustness, and reliability, while meeting specifications. Students will have the opportunity to develop these skills by working on their own code and in group projects.

COS 333 is about programming, not about a specific language. For the most part, the course will use the C programming language, with excursions into C++, Java, and scripting languages like shells, Awk, Perl, and Tcl. There will be significant emphasis on tools, both how to use them and how they are designed and built. The course will use Unix and Linux more than Windows, but not exclusively. Students should be comfortable with C programming and Unix; COS 217 is a prerequisite.

Draft Syllabus

This syllabus is definitely subject to change. Each topic will take roughly one week.

This is meant to be more than a laundry list, however. Each section will also discuss issues of design, implementation, testing, performance, portability, and other software engineering concerns, and these will also be part of the programming assignments. With luck there will be a few guest lecturers as well.

Mechanics

There will be two lectures each week. During the first half of the semester, there will be a modest-sized programming assignment each week, which should take perhaps 5 hours to complete. During the second half of the semester, students will work in groups of 3 or 4 on a project that will involve a significant amount of design and implementation.

There are two required texts for the course: The Unix Programming Environment and The Practice of Programming, by Kernighan and Pike. Other readings will be handed out in class or found on the Web. The books listed in this bibliography are also worth looking at; they cover a wide variety of material related to programming.

Lectures:
Tuesday and Thursday 11:00-12:20, CS 103.

Professor:
Brian Kernighan, 311 CS Building, 609-258-2089, bwk@cs.princeton.edu. Office hours: By appointment; just send mail.

Teaching Assistants:
Carl Kingsford, carlk@cs, 258-0254. Office hours: 1:00-2:00 Tuesdays and by appointment
Nitin Garg, nitin@cs, 258-5386. Office hours: 3:00-4:00 Fridays and by appointment

For most questions about the course, check the newsgroup first; this will be monitored by the TA's, and their answers will be posted for everyone's benefit.

Assignments

Five programming assigments will be assigned during the first half of the term; each is intended to take about five hours, but is sure to take longer unless you are careful.

Assignments are together worth about 30 percent of the course grade. Assignments are due by midnight on Thursdays unless there are extraordinary circumstances; each 12 hours or fraction of lateness thereafter incurs a 25% penalty (so assignments turned in after 1:00 PM Saturday receive no credit). You must complete all assignments to pass the course.

Project

The second half of the semester will be devoted to a group project; more details will be given soon. The project can be done in whatever combination of languages and techniques makes most sense; one of the goals of the project is to encourage careful tradeoffs among alternatives, and planning of interfaces to minimize dependencies. The project is thus a good place to explore personal interests further than can reasonably be covered in class.

The project will have checkpoints along the way for which you will have to turn in status reports, preliminary designs, and the like.

The project will be worth 60 percent of the course grade; it will be shared equally among group members, with the possibility of negative adjustments for group members who fail to contribute their fair share.

In-class Quizzes

There will be unannounced, very short, in-class quizzes to test understanding and verify existence. These will be worth 5-10 percent of the course grade.

Collaboration Policy

(This policy on collaboration is adapted from the CS 217 web page.) Programming, like composition, is an individual creative process. Individuals must reach their own understanding of the problem and discover a path to its solution. During this time, discussions with friends are encouraged. However, when the time comes to write the code that solves the problem, such discussions are no longer appropriate - the program must be your own work (although you may ask teaching assistants for help in debugging). If you have a question about how to use some language or operating system feature, you can certainly ask your friends or the teaching assistants.

These rules apply to each project group as well: group members can share everything among themselves, but groups may not collaborate with each other.

Do not, under any circumstances, copy another person's program. Writing code for use by another or using another's code in any form violates the University's academic regulations.

Examples of unacceptable behavior include:

The program you turn in must be your work. You may get help from the instructor or TA after you have started writing code, but not from other students. Computer science assignments are not like physics or math problem sets: there is no single right answer. Each student is expected to come up with his or her own individual solution.

If you plan to do something that you are not absolutely sure is legal, ask one of us first. Ignorance of this policy will not be accepted as an excuse for your actions.

You are responsible for ensuring that your files are not readable by your classmates. We recommend doing your CS333 work in a private subdirectory, i.e.: 

% mkdir cs333
% chmod 700 cs333