\documentclass[12pt]{article}
% \usepackage{fullpage}
\advance \textheight by \topmargin
\advance \textwidth by \oddsidemargin
\topmargin 0pt
\oddsidemargin 0pt
\evensidemargin 0pt

\begin{document}

\title{Computer Science 171 \\
Introduction to Computer Programming}

\author{Dr. Stephen Bloch \\
office 112 Alumn\ae\ Hall \\
phone 877-4483 \\
email \texttt{sbloch@adelphi.edu} \\
Web page \texttt{http://www.adelphi.edu/sbloch/} \\
Class Web page \texttt{http://www.adelphi.edu/sbloch/class/171/} \\
office hours 1:00-2:15 most weekdays, plus Tuesday 9:00-1:00}

\maketitle

\section{Subject Matter --- Overview}
Computers do many of the same things people do, only faster, more
accurately, and without getting bored.
Accordingly, the task of programming a computer is essentially the task
of figuring out exactly how \emph{you} would solve a particular problem,
and then explaining it to the computer.  Unfortunately, computers are
literal-minded and completely devoid of intuition, so your explanation
must be much more precise and unambiguous than if you were explaining
things to a human being.  This course, therefore, is about how to
analyze a problem, figure out precisely and unambiguously how to solve
it, and present this explanation to a computer.

In a broader sense, this course is about problem-solving, and about a
particular way of approaching the world which we may call \emph{algorithmic
thinking}.  I consider computer science a ``liberal art''
providing training in how to think, regardless of whether you choose it as
a profession.

\section{Who Should Take This Course}
If you're a computer science or information systems major, you must take this course as early
as possible, preferably in your first semester at Adelphi.  If you're a
computer science minor, you must take this course in your first two
years at Adelphi.  If you're majoring in mathematics, pre-engineering,
or perhaps some other fields, you must take this course at some point.
If you're curious about how computers work, what programming is like,
and how programmers think, this is a good course to take.
If you have no interest in
writing significant programs of your own, but simply want to \emph{use} Web
browsers and search engines, spreadsheets, databases, word processors,
\emph{etc.} and perhaps write your own Web pages, you should 
take CSC 170 instead.

\section{Prerequisites}
This course has no prerequisites.  Students are not expected to know how
to program, use, or even turn on a computer.  However, students who have
done some programming in a different language 
may still benefit from the course; consult the professor.

\section{Subject Matter --- More Details}
\subsection{``Good'' Programs}
What distinguises a ``good program'' from a ``bad program''?  Obviously,
a good program has to work correctly and reliably~--- a difficult goal
in itself, as we'll see.  But this is far from enough.
In practice, very few programs are written once, used for a
while, and discarded: much more often, a program is used until the need
for it changes, the program is \emph{modified} to handle the new
requirements, the modified program is used for a while, and the cycle
repeats.  Thus a ``good program'' must be not only correct the first time
around, but structured in such a way that it can easily be modified to
accomodate likely changes in requirements.  The implications of this
fact will follow you throughout your years as a computer science
student and your career as a computer professional;
we'll only scratch the surface this semester.

\subsection{Kinds of Knowledge}
An introductory programming course is in some sense an almost impossible
task.  In one semester, you'll be asked to learn several different kinds
of knowledge:
\begin{enumerate}
\item How to use the computers and the software on them
\item The grammar, punctuation, and vocabulary of a programming
language
\item How to analyze a problem and design a program to solve it, so that
the program is both correct and easy to write, read, modify, and repair
\item How to plan your time, and what sequence of steps to go through,
in designing, writing, testing and debugging a program
\item Application-specific knowledge (\emph{e.g.} to write a program
that draws geometric shapes on the screen, you have to know something
about geometry.)
\end{enumerate}
It is easy for a student (or a professor or a textbook author, for that
matter) to get caught up in the details of the first two at the expense
of the rest.  I urge you \emph{not} to fall into this trap, because the
specific kinds of computers and software, and to some extent the
language, you learn this semester will almost certainly be obsolete by
the time you leave Adelphi.  The much more interesting and lasting
knowledge is at levels 3, 4, and 5 (and I'll try to minimize the time we
spend on level 5 because it's not specific to computer science). 
In short, although all five kinds of knowledge are necessary in order to
write a good program, I'll try to concentrate on levels 3 and 4.

\subsection{Language and design recipes}
In 1998, I taught this course in the Java programming language, and
found that we spent \emph{far} too much of our time on level-1 and
level-2 knowledge, with not enough time left for levels 3 and 4.
So in 1999 I started in the Scheme language, which has
simpler rules of grammar, punctuation, and vocabulary and is 
easier to use, and switched to Java for the second semester.
It worked well --- indeed, I think the students who switched
from Scheme to Java came out with a better understanding of Java than those
who started in Java from the beginning --- so we'll do much the same this year.

We'll pay a lot of attention to \textbf{design patterns}, which are
step-by-step ``recipes'' for getting from a vague English-language
description of a problem to a working computer program.  Last year's
students tended to skip the recipes when they were in a hurry, and
invariably found themselves wasting more time as a result.  To prevent
this, \textbf{you will be graded} on, among other things, how well and
thoroughly you use the recipes.

\subsection{Knowing your Tools}
If you wanted to learn carpentry, you would start by studying the
characteristics and capabilities of each of the common tools carpenters
use, so you use the right tool at the right time for things that it does
well.  In programming, although you have editors, compilers, etc. to
help, your main tool is your mind; accordingly, it makes sense to study
the characteristics and capabilities of your mind.  Indeed, it can be
studied and measured just as scientifically as a bouncing ball in
Physics class.  By the end of the semester, you should have a much
better idea (backed up with hard numbers) of how \emph{you} work as a
programmer, and hence the ability to accurately estimate how long
\emph{you} will need to complete a specified programming task.  This
allows you to plan ahead and complete assignments on time --- an
invaluable skill for a professional programmer, and applicable to the
(non-programming) rest of your life as well!

\section{Texts}
I'm using two different textbooks for this course.
For levels 1, 2, 3, and part of 4, we'll use \emph{How to Design Programs},
by Felleisen, Findler, Flatt, and Krishnamurthi (who also wrote the
programming platform we'll use, DrScheme).  This book is due to be
printed ``any day now'' by MIT Press, but it's already available on the
Web at \\*
\texttt{http://www.cs.rice.edu/CS/PLT/Teaching/Lectures/Released/Book/}.
Some of the later chapters are still being written, but they should be
complete by the time we get to them.

For more level-4 knowledge, we'll use \emph{Introduction to the Personal
Software Process}, by Watts Humphrey (Addison-Wesley 1997, ISBN
0-201-54809-7).  This book discusses how to keep track of problems you
encounter in programming, so as to prevent them in the future, and how
to manage your time so as to finish programming assignments before
they're due.  (The easiest way to fail my class is to fail to turn in
homework assignments!)

You'll need to read an average of about 50 pages a week.
\textbf{You are responsible for everything
in the reading assignments, whether or not I discuss it in a lecture.}
You are also responsible for checking my class Web page and the WebBoard
discussion group at least once a
week or so; I often post assignments, corrections to assignments,
solutions to assignments, \emph{etc.} there.

\section{Grading}
I expect to give approximately ten programming assignments --- one
every week or two, due the following week.
Most assignments are to be turned in by email, and will be considered late
if the time stamp on the email is after midnight on the assigned due
date.  Assignments turned in up to a day late lose 30\% credit; those up
to two days late lose 60\% credit; and beyond that, they'll lose 90\%
credit (\emph{i.e.} the best grade you can hope for is 10\%.)
Any homework assignment turned in after midnight, Monday, Dec. 11 (the second
to last day of class) will get a zero.

I also plan half a dozen brief in-class quizzes (say,
15 minutes each), mostly on level-2 language issues.  Which I said I wasn't
particularly interested in, but you \emph{do} need to know it in order to do
your assignments, and these quizzes seem the best way to make sure
everybody learns the language.
Each quiz will count for 2\% of your semester grade.  Quizzes cannot be made
up; if you're not there the day I give the quiz, you get a zero on it.

% These numeric grades will be converted to letter grades as follows:
% I'll draw a curve showing the distribution of numeric grades, and look
% for naturally-occurring ``clumps''.  For each clump, especially the
% top and bottom ones, I'll examine some exam and
% homework papers to decide what letter grade seems appropriate.  This
% method corrects for excessively hard or excessively easy assignments
% while not penalizing anybody for having genius classmates.

We'll also have a two-hour final exam on December 18 or 20 (depending on
which section you're in), weighted the same
as a programming assignment: 
for example, if there are 6 quizzes, 10 programming assignments, and a final
exam, each quiz will be worth 2\%, each programming assignment will be worth
8\%, and the final exam will also be worth 8\%.  The precise numbers may
vary a little from this.
The final exam must be taken at the scheduled time, unless arranged in advance
or prevented by a documented medical or family 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.
% (and I'd
% prefer it if you let me know earlier --- you should know within the
% first week of class when all your exams are).
Exams not taken without one of
the above excuses will be recorded with a grade of 0.

\section{Program standards}
Every program must contain, in the first few lines, a comment indicating the name(s)
of the student(s) 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 saved ``Interactions window'' (I'll explain
how to do this in the first week) showing how the program works on test cases.
Programs with inadequate or poorly-chosen test cases will lose points (we'll discuss
how to choose good test cases); programs turned in with no test runs at all will lose
\emph{lots} of points.

Having done my share of programming, I know that sometimes you hit a brick wall and cannot
get the thing to work for love or money.  If this happens, turn in the program together with
a concise description of how the program fails, what you've tried in your attempts
to fix it, and how those attempts didn't succeed.  You won't get full credit, but if I'm
convinced that you're working on it diligently, you'll get some partial credit.
Note that ``how the program fails'' does \emph{not} mean saying ``I got an error message;''
you need to tell me \emph{which} error message you got, \emph{when} you saw it, and
\emph{what} you think the error message means.  Similarly, if the program fails by producing
wrong answers, you need to tell me \emph{when} it produces wrong answers
(are they \emph{all} wrong, or just in a few cases?),
\emph{how} they are wrong (\emph{e.g.} are all the numbers consistently higher than you expected,
are they the negatives of the correct answers,
or are they all over the place with no apparent pattern?), and your speculations on \emph{how}
such an error might have arisen.  I'm requiring all this not because I'm mean and horrible, but
because by the time you've written all this down, you may have enough information to actually
\emph{fix} the problem, which is much better than turning it in incomplete.

I also expect you to keep track of the time you spend on various aspects of programming,
how many and what kinds of defects you encounter, \emph{etc.}  For each assignment, I'll tell you
which tracking information is required.  The easiest way to turn in this information is through
a collection of on-line forms, which I'll show you how to use.  Indeed, I recommend that while
you're programming, you have a Web browser running the forms in the background, so you can easily
record each defect and each block of time before you forget about it.  Failure to turn in this
tracking information will lower your grade for that assignment.

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

\section{Ethics}
Most homework assignments in this course involve writing, testing, and
debugging a program.  For most of these assignments, you are to work in
teams of two students (switching teams from one assignment to the next);
for other assignments, I may ask you to work individually.

When I say
``teams of two students'', I don't mean ``you write the first half of the
assignment, and I'll write the second half''; I want \emph{both} students
working \emph{together} on \emph{all} of the assignment, using the techniques
of Pair Programming (on which I'll give you a reading assignment).

It's hard to define what constitutes ``cheating'' in this sort of
course.  Students are encouraged to help one another with level-1 and
level-2 difficulties (``how do I save this file?'', ``what's the syntax
for \texttt{define-struct}?'', \emph{etc.}), regardless of whether
they're on the same team, but designing, coding, testing, and debugging 
should be done by team members.  It's remarkably easy for a professor to
notice when three different teams have turned in nearly-identical
programs; if that happens, I'll grade it once and divide the credit
among the three, so the best any of them can hope for is 33\%.

All work on the final exam and the quizzes must be entirely the work of the one
person whose name is at the top of the page.  If I have evidence that
one student copied from another on an exam or quiz, \emph{both} students will be
penalized; see above.

% \pagebreak

\section{Schedule}
Section 1 of this class meets every Monday and Wednesday from 9:25 to 10:40 AM in
Science 227; the final exam is Wednesday, Dec. 20, from
8:00-10:00 AM. \\
Section 2 meets every Monday and Wednesday from 2:25 to 3:40 PM in
the Gallagher lab in the Library; the final exam is Monday, Dec. 18, from 3:30--5:30 PM.

All dates in the following schedule are tentative, except those fixed
by the University; if some topic listed here as taking one lecture in
fact takes two lectures to cover adequately, or \emph{vice versa},
the schedule will shift.  I'll try to keep this information up to date
on the class Web page.

In the column marked ``Reading'', the letters ``HtDP'' precede section
numbers in \emph{How to Design Programs},
while the letters ``PSP'' precede section numbers in
the Humphrey textbook on the Personal Software Process.  There may also
be other reading assignments provided on the Web.

% In no case will an assignment be due earlier than indicated in the
% following schedule, but some may be due later; this will be announced
% in class a reasonable time in advance.  I'll try to keep an updated
% version of this schedule available online.  

I expect you to have read the reading assignments (usually about 25
pages per lecture)
\emph{before} the lecture that deals with that topic.  
This way I can
concentrate my time on answering questions and clarifying subtle or
difficult points in the textbook, rather than on reading the textbook
to you, which will bore both of us.  \textbf{Please read ahead!}

When I say ``read'' above, I
mean an active process, involving not only the textbook but
pencil, scratch paper, and a notebook for writing down key points.
Finally, and perhaps most importantly, you'll need a computer for trying
out the new ideas you find in your reading.  Just as you cannot learn
about cooking or driving a car just by reading about it, you cannot
learn about programming just by reading about it.  In short,
\emph{every} time you read about a new programming idea, \emph{try it!}
The \emph{How to Design Programs} textbook contains lots of exercises,
which you are encouraged to do as you come to them in the text, whether
assigned as homework or not.

\subsection{Schedule for Section 1 (9:25 AM)}

blah

\subsection{Schedule for Section 2 (2:25 PM)}

blah
% 
% \pagebreak
% 
% \subsection{Schedule for Sections 1 and 3}
% % Classes meeting after 3 PM start Sept. 1; others start Sept. 2.
% % Classes meeting after 3 PM are off 29 Sept.
% \begin{tabbing}
% {\bf Date(s)} \=
% {\bf Assignment \hskip1.5em} \=
% {\bf Reading \hskip4em} \=
% {\bf Subject} \kill
% {\bf Date(s)} \>
% {\bf Assignment} \>
% {\bf Reading} \>
% {\hskip3em \bf Lecture Subject} \\
% %
% 2 Sept \> HW1 \> \> Administrivia, survey, accounts, passwords, 
% \\* \> \> \> email, Web, using the lab \\
% 7 Sept \> HW1 due \> HtDP through 2.2, \> Using DrScheme \& stepper; arithmetic expressions,
% \\* \> \> PSP 1 \>  data types, variables, defining functions \\ % 27 pp.
% 9 Sept \> HW2 \> HtDP 2.3--2.7, \> Errors and debugging; design recipe;
% \\* \> \> PSP 11.1--11.3 \>  pair programming; program development cycle \\ % 17 pp.
% 13 Sept \> \> \> Deadline to add classes \\
% 14 Sept \> \> HtDP 3, PSP 12 \> Conditionals, defect tracking and removal \\ % 38 pp.
% 16 Sept \> HW2 due; HW3 \> HtDP 4, PSP 13 \> Symbols and code review \\ % 22 pp.
% 21 Sept \> \> HtDP 5 \> Compound data and design recipes for them;
% \\* \> \> \>  iterative refinement \\ % 32 pp.
% 23 Sept \> HW3 due; HW4 \> PSP 14 \> Code review checklists \\ % 18 pp.
% 24 Sept \> \> \> Deadline to drop classes \\
% 28 Sept \> \> HtDP 6--I1 \> Mixed data, design recipes for them \\ % 30 pp.
% 30 Sept \> HW4 due; HW5 \> HtDP 8 \> Lists and design recipes for them \\ % 18 pp.
% 5 Oct \> \> HtDP 9, PSP 2 \> List processing; time management \\ % 28 pp.
% 7 Oct \> HW5 due; HW6 \> HtDP 10 \> Natural numbers and recursion on them \\ % 22 pp.
% 12 Oct \> \> HtDP 11--I2, PSP 3 \> Examples; time tracking \\ % 28 pp. Sorting, smoothing, elevators....
% 14 Oct \> HW6 due; HW7 \> HtDP 13 \> More recursive data structures \\ % 20 pp.
% 19 Oct \> \> \> I'm at a conference; sub or no class \\ 
% 21 Oct \> \> HtDP 14 \> More recursive data structures \\ % 12 pp.
% 26 Oct \> \> HtDP 15--16 \> Iterative refinement and multiple complex data \\ % 31 pp.
% 28 Oct \> HW7 due; HW8 \> HtDP I3, PSP 5 \> Code estimation \\ % 29 pp.
% 2 Nov \> \> HtDP 18 \> Abstracting designs \\ % 15 pp.
% 4 Nov \> \> HtDP 19, I4, PSP 6 \> Programs as data \\ % 28 pp.
% 5 Nov \> \> \> Deadline to withdraw from classes \\
% 9 Nov \> \> HtDP 20--21 \> Using abstractions \\ % 26 pp.
% 11 Nov \> HW8 due; HW9 \> HtDP 23--24 \> Generative recursion \\ % 22
% pp.
% 16 Nov \> \> HtDP 25 \> More on recursion \\ % 15 pp.
% 18 Nov \> \> HtDP 27--28 \> Accumulative recursion \\ % 27 pp.
% 23 Nov \> HW9 due; HW10 \> HtDP 29--31 \> More on accumulators \\ % >= 17 pp. 
% 25 Nov \> \> \>	Thanksgiving break --- no classes \\
% 30 Nov \> HW10 due; HW11 \> HtDP 32 \> History and State \\ % ?? pp.
% 2 Dec \> \> HtDP 33 \> Modifying compound data \\ % ?? pp.  
% 7 Dec \> \> \> Catch up and review \\
% 9 Dec \> HW11 due \> \> Catch up and review for final exam \\
% 16 Dec \> \> \> 10:30 AM -- 12:30 PM, final exam for section 3 \\
% 16 Dec \> \> \> 1:00 -- 3:00 PM, final exam for section 1 \\
% \end{tabbing}
% 
% \pagebreak
% 
% \subsection{Schedule for Section 2}
% \begin{tabbing}
% {\bf Date(s)} \=
% {\bf Assignment \hskip1.5em} \=
% {\bf Reading \hskip4em} \=
% {\bf Subject} \kill
% {\bf Date(s)} \>
% {\bf Assignment} \>
% {\bf Reading} \>
% {\hskip3em \bf Lecture Subject} \\
% %
% 1 Sept \> HW1 \> \> Administrivia, survey, accounts, passwords,
% \\* \> \> \>  email, Web, using the lab \\
% 6 Sept \> \> \> Labor Day --- no classes \\
% 8 Sept \> HW1 due \> HtDP Preface--2.2, \> Using DrScheme \& stepper; arithmetic expressions,
% \\* \> \> PSP 1 \>  data types, variables, defining functions \\ % 27 pp.
% 13 Sept \> \> \> Deadline to add classes \\*
% \> HW2 \> HtDP 2.3--2.7, \> Errors and debugging; design recipe;
% \\* \> \> PSP 11.1--11.3 \>  pair programming; program development cycle \\ % 17 pp.
% 15 Sept \> \> HtDP 3, PSP 12 \> Conditionals, defect tracking and removal \\ % 38 pp.
% 20 Sept \> \> \> Yom Kippur --- no classes \\
% 22 Sept \> HW2 due; HW3 \> HtDP 4, PSP 13 \> Symbols and code review \\ % 22 pp.
% 24 Sept \> \> \> Deadline to drop classes \\
% 27 Sept \> \> HtDP 5 \> Compound data and design recipes for them;
% \\* \> \> \>  iterative refinement \\ % 32 pp. 
% 29 Sept \> HW3 due; HW4 \> PSP 14 \> Code review checklists \\ % 18 pp.
% 4 Oct \> \> HtDP 6--I1 \> Mixed data, design recipes for them \\ % 30 pp.
% 6 Oct \> HW4 due; HW5 \> HtDP 8 \> Lists and design recipes for them \\ % 18 pp.
% 11 Oct \> \> HtDP 9, PSP 2 \> List processing; time management \\ % 28 pp.
% 13 Oct \> HW5 due; HW6 \> HtDP 10 \> Natural numbers and recursion on them \\ % 22 pp.
% 18 Oct \> \> \> I'm at a conference; sub or no class \\
% 20 Oct \> \> HtDP 11--I2, PSP 3 \> Examples; time tracking \\ % 28 pp. Sorting, smoothing, elevators....
% 25 Oct \> HW6 due; HW7 \> HtDP 13 \> More recursive data structures \\ % 20 pp.
% 27 Oct \> \> HtDP 14 \> More recursive data structures \\ % 12 pp.
% 1 Nov \> \> HtDP 15--16 \> Iterative refinement and multiple complex data \\ % 31 pp.
% 3 Nov \> HW8 \> HtDP I3, PSP 5 \> Code estimation \\ % 29 pp.
% 5 Nov \> \> \> Deadline to withdraw from classes \\
% 8 Nov \> HW7 due \> HtDP 18 \> Abstracting designs \\ % 15 pp.
% 10 Nov \> \> HtDP 19, I4, PSP 6 \> Programs as data \\ % 28 pp.
% 15 Nov \> \> HtDP 20--21 \> Using abstractions \\ % 26 pp.
% 17 Nov \> HW8 due; HW9 \> HtDP 23--24 \> Generative recursion \\ % 22 pp.
% 22 Nov \> \> HtDP 25 \> More on recursion \\ % 15 pp.
% 24 Nov \> \> HtDP 27--28 \> Accumulative recursion \\ % 27 pp. 
% 29 Nov \> HW9 due; HW10 \> HtDP 29--31 \> More on accumulators \\ % >= 17 pp.  
% 1 Dec \> \> HtDP 32 \> History and State \\ % ?? pp.
% 6 Dec \> \> HtDP 33 \> Modifying compound data \\ 
% 8 Dec \> \> \> Catch up and review \\
% 13 Dec \> HW10 due \> \> Catch up and review for final exam \\
% 20 Dec \> \> \> 3:30 -- 5:30 PM, final exam for section 2 \\
% \end{tabbing}
\end{document}
% 
% HW1: Solo.
% Fill out surveys.
% Use a Web browser to visit the class page and read some of the adages.
% Read PSP chap. 1.
% Write a brief essay on what you've done with computers in the past,
% what you hope to do with them in the future, what you hope to do with
% them this semester, and your reaction to PSP chap. 1 and to the adages
% you've read.
% Turn in by email.
% 
% HW2: In pairs.
% Defining functions (exercises from chap. 2 HtDP?)  Defect recording log.
% 
% HW3: In pairs.
% Conditionals and symbols (exercises from chap. 3, 4 HtDP?)  Code review.
% 
% HW4: In pairs.
% Compound data.  (Chap. 5 HtDP)  Code review checklist.
% 
% HW5: In pairs.
% Mixed data, lists.  (Chaps. 6-9 HtDP).
% 
% HW6: In pairs.
% Natural number recursion. (Chap. 10 HtDP).
% 
% HW7: In pairs.
% Non-list recursive data structures. (Chaps. 11-12 HtDP).  Time log.
% 
% HW8: In pairs.
% Mutually recursive data structures, multiple complex data.
% Project plan with estimated time.
% 
% HW9: In pairs.
% Generative recursion, code abstraction.  Project plan with estimated
% LOC, time.
% 
% HW10: In pairs.
% Accumulative recursion.
% 
% HW11: In pairs.
% Stateful computation.
% 
% Final exam: Solo.  Comprehensive.
