August 28, 2003
Students taking this course are expected to have successfully completed CSC 171 ("Introduction to Computer Programming") and CSC 172 ("Introduction to Algorithms and Data Structures"), or their equivalents at another school. If you took these courses at another school, or if you're taking CSC 172 concurrently, please discuss it with me privately to decide whether you should take this course and what you and/or I need to do to adapt. This is largely a programming course, so students should expect to spend a lot of time designing, writing, testing, and debugging programs.
If you're taking this course, you are already comfortable with the notion of writing a program, and you've learned some of the techniques and data structures most often used in computer programs. But you've probably only worked in one or two languages (e.g. Scheme, Java, C++, C, Visual Basic), of the literally hundreds of languages out there, each of which has its own strengths and weaknesses. A programmer who approaches every problem by thinking about how to solve it in Java is like a carpenter who uses a hammer on everything, even when a saw or a screwdriver would be more appropriate. A competent programmer must be able to select the most appropriate language for any given problem. Furthermore, a competent programmer must be able to write idiomatically in each language, i.e, to write in the style to which that language is suited: don't be like the carpenter who correctly chooses a screwdriver, but still uses it like a hammer. Finally, a competent programmer must be able to learn a new language and its idiom quickly.
We'll spend the first few weeks discussing the history and theory of programming languages, in particular the five we'll work on this semester: C, C++, Java, Scheme, and Prolog. After that, the course will be largely self-paced: you'll choose which programs to write in which order so as to demonstrate to me that you know what you're doing in each language. When a number of students are curious about the same topic or language, I'll discuss it in one corner of the classroom, while allowing others to work on other tasks. Feel free to request particular topics, ideally by e-mail in advance so I have some time to prepare.
I've ordered several "textbooks" through the Bookstore; which you actually need depends on your individual background.
Timothy Budd's C++ for Java Programmers. Obviously, this will be most helpful for people who have already studied Java and want to learn C++.
Sierra & Bates's Head First Java. This will be most helpful for those who already know another language, like C++ or VB, and want to learn Java. Those who have already studied Java may find it useful too.
Bjarne Stroustrup's The C++ Programming Language. (Actually, I haven't ordered this through the campus bookstore, but it's available in the library and from any mainstream bookstore.) Stroustrup invented C++, almost single-handedly, in the early 1980's, and his book is still the definitive reference on it. He also included a lot of good advice on object-oriented programming and design.
On-line textbook for Scheme at
On-line tutorial for Prolog at
Since all the students in this course have different language backgrounds, I don't plan to give out the same assignments to everyone, due at the same time. Instead, I've posted on the Web a list of skills I expect you to master in each language (as well as a category of "language-independent skills"). You'll choose programming assignments to do that demonstrate your mastery of various skills. Whenever you turn in a program, I'll go through each of the skills you've demonstrated in that program and assign a numeric score:
0 for "didn't use the skill"
1 for "used it slightly or poorly"
2 for "used it reasonably well"
3 for "fluent, comfortable, idiomatic".
These numbers will be multiplied by weighting factors:
"essential" skills are weighted at 3
"important" skills are weighted at 2
"obscure" skills are weighted at 1.
If you demonstrate a particular skill at level 1 on one program, then later turn in another program in the same language using it at level 2 or 3, I'll keep the highest score for that skill. Scores on the language-independent skills will be averaged, rather than keeping the highest. By the end of the semester, you'll have earned a number of points in each language; I'll divide this by the number of possible points in that language, and average together the grades for the five languages, the "language-independent skills", and the comprehensive final exam. As a guideline, earning 40% of the possible points in each language is probably a C; earning 60% is probably a B; and earning 80% is probably an A.
Any homework assignment turned in after midnight, Friday, Dec. 12 (the last day of class) will get only partial credit; any turned in after midnight, Tuesday, Dec. 16 (the day before final exams) will be thrown away ungraded. Other than that, there are no specific due dates, but try to earn as many points as possible early in the semester, so you're not stuck against the deadline, just when your term projects in other classes are due (and so I don't have a mountain of grading to do in the last few days!). For example, I recommend starting with the language(s) most familiar to you.
We'll have a two-hour final exam on Dec. 17, from 8:00-10:00 AM. The final exam is comprehensive: it may include questions about any of the five languages, about programming languages in general, or about which language you would choose to solve a particular problem.
The final exam must be taken at the scheduled time, unless arranged in advance or prevented by a documented medical or family emergency. (Staying up late the night before to see Return of the King does not qualify as an emergency!) If you have three or more exams scheduled on the same date, or a religious holiday that conflicts with an exam or assignment due date, please notify me in writing within the first two weeks of the semester in order to receive due consideration. Exams not taken without one of the above excuses will be recorded with a grade of 0.
Every program must contain, in the first few lines, a comment indicating the name of the student working on it and which assignment it is. Programs not containing this information, clearly visible, will get a zero.
Every program must be accompanied by a session log (I'll show you how to do this) showing how the program works on test cases. Programs with inadequate or poorly-chosen test cases will lose points; programs turned in with no test runs at all will lose lots of points.
Every program must be adequately and accurately commented, as appropriate in the current language.
For those of you who used PSP in CSC 160, 171, or 172, I've set it up (and improved it somewhat) for this class's use too. You are invited to use it to record your time, program size, and defects encountered, but I don't plan to grade it this semester.
Programs are not abstract works of art, they are supposed to run and solve real problems. So if I get a program that doesn't compile or run, or a program that has little or nothing to do with the problem I assigned, I will give it a zero, no matter how much time you put into it. Don't bother turning in a program you haven't tested yourself.
Most homework assignments in this course involve writing, testing, and debugging a program by yourself. You are welcome to seek help on mechanical and syntactic matters ("how do I save this file?", "how do I get a session log?" "what does this compiler error message mean?") from me, from other students in the class, and from tutors in the Learning Center; however, for higher-level tasks of design, coding, testing, and debugging, I expect you to work by yourself. If I see that three different people have turned in nearly-identical programs, I'll grade it once and divide the credit among the three, so the best any of them can hope for is 33%.