1 Who Should Take This Course

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.

2 Subject Matter

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.

3 Texts

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.

4 Grading

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.

5 Program standards

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.

6 Ethics

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%.