\documentclass[12pt]{article}
\usepackage{fullpage}

\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 TBA}

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

\section{Who Should Take This Course}
If you're a computer science 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 and what programming is like,
this is probably a good course to take.  If you have no interest in
writing significant programs of your own, but simply want to use Web
browsers and search engines, spreadsheets, databases, word processors,
\emph{etc.} and perhaps write your own Web pages, you should probably
take CSC 170 instead.

\section{Subject Matter --- More Details}
\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 the Java 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{``Good'' Programs}
What distinguises a ``good program'' from a ``bad program''?  Obviously,
a good program has to work correctly and reliably.  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{Language and methodology}
Although the first computer programs were written in the 1940's, it was
only in the 1960's that researchers started seriously studying the
\emph{human} process of computer programming, in an effort
to systematize how to write correct, reliable, modifiable programs.
The results
were presented as a series of ``programming methodologies'' --- Modular
Programming, Structured Programming, Object-Based Programming, and most
recently Object-Oriented Programming, or OOP --- each of which subsumed the
lessons of its predecessor and added new principles for designing ever
larger and more complex programs.  This semester we'll work in the Java
programming language, which was designed for OOP,
and which has the added benefit that programs
written in Java can use the Internet, and be incorporated into World
Wide Web pages, relatively easily.

\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 non-object-oriented language will still
benefit from the course.

\section{Texts}
I'm using two very different textbooks for this course.
The longer and more conventional one is
\emph{Introduction to Programming Using Java: an Object-Oriented Approach},
by David Arnow and Gerald Weiss, published by Addison-Wesley, ISBN
0-201-31184-4.
We'll also use \emph{A Little Java, A Few Patterns} by Matthias
Felleisen and Daniel P. Friedman, MIT Press, ISBN 0-262-56115-8.
The latter book may feel like ``kid stuff'' at times, what with the
cartoons and the chatty style, but it's actually by far the more
mind-stretching of the two, and you'll need to read it very carefully. 
I'll give reading assignments from both textbooks in alternation.

You'll need to read an average of about 40 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 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 nine or ten programming assignments --- roughly one
a week, 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\%.)

% 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 22, weighted the same
as a programming assignment: that is, there are 9 programming assignments,
each of them will be worth $10\%$ of your semester grade,
and the final exam will also be worth $10\%$.
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.

% 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.  Although I may give one or two assignments to
be done (and turned in) by teams of two, most assignments are to be done
individually.  If I see essentially identical programs turned in by three
different people (not hard to spot, when one professor is in charge of
all the students), I'll grade it once and divide the points among those
students, so the best grade any of them can hope for is a 33\%.

All work on the final exam 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, \emph{both} students will be
penalized; see above.

% \pagebreak

\section{Schedule}
Section 1 of this class meets every Tuesday and Thursday from 10:50 AM
to 12:05 PM in Business 39.
Section 2 meets every Tuesday from 6:00-8:30 PM in Business 33.
Section 3 meets every Tuesday and Thursday from 9:25 to 10:40 AM in Business 39.
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.

In the column marked ``Reading'', the letters ``AW'' precede page
numbers in the Arnow
\& Weiss textbook, while the letters ``FF'' precede page numbers in
the Felleisen \& Friedman textbook.

% 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 20
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 a fairly 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.  So I emphasize:
\emph{every} time you read about a new programming idea, \emph{try it!}

\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 \hskip1em} \=
{\bf Reading \hskip2em} \=
{\bf Subject} \kill
{\bf Date(s)} \>
{\bf Assignment} \>
{\bf Reading} \>
{\hskip3em \bf Lecture Subject} \\
%
3 Sept \> HW1 \> \> Administrivia, accounts, passwords, using the lab \\
8 Sept \> \> AW pp. 1--22 \> Objects, classes, and messages \\
10 Sept \> \> \> The software development process; design recipes \\
11 Sept \> \> \> Last day to add courses \\
15 Sept \> HW1 due; HW2 \> AW 23--56 \> Examples with printing, strings, and variables \\
17 Sept \> \> AW 57--87 \> Examples with classes for input \& output \\
22 Sept \> \> \> No classes; Rosh Hashanah \\
24 Sept \> HW2 due \> \> catch up on previous week \\
25 Sept \> \> \> Last day to drop courses \\
29 Sept \> HW3 \> FF 3--11 \> Defining classes, constructors, instance variables \\
1 Oct \> \> FF 13--27 \> Defining classes with methods \\
6 Oct \> HW3 due \> FF 28--41 \> Inheritance, overriding, and abstract classes \\
8 Oct \> HW4 \> AW 89--109 \> Another view of class definition \\
13 Oct \> \> AW 109--139 \> Another example; state and behavior \\
15 Oct \> HW4 due \> AW 141--161 \> How to design a class \\
20 Oct \> HW5 \> AW 161--187 \> Numbers, literals, constants, text \\
22 Oct \> \> AW 189--209 \> Conditionals and booleans \\
27 Oct \> HW5 due \> FF 43--54 \> Conditionals and booleans: another view \\
29 Oct \> HW6 \> AW 209--243 \> Logical operators, "equals", event-handling \\
30 Oct \> \> \> Last day to withdraw from classes \\
3 Nov \> \> AW 245--263 \> Another look at testing and debugging \\
5 Nov \> HW6 due \> AW 265--291 \> Collection classes and loops \\
10 Nov \> HW7 \> AW 292--314 \> Defining new collection classes \\
12 Nov \> \> AW 315--337 \> More on loops \\
17 Nov \> HW7 due \> AW 338--377 \> Loops and Threads \\
19 Nov \> HW8 \> FF 57--83 \> Another kind of iteration: visitor classes \\
24 Nov \> \> FF 85--97 \> Visitors and interfaces \\
26 Nov \> \> \> No classes: Thanksgiving \\
1 Dec \> HW8 due \> AW 379--400 \> Vectors, searching, and efficiency \\
3 Dec \> HW9 \> AW 401--426 \> Searching and sorting, arrays, strings \\
8 Dec \> \> AW 427--460 \> ``Game of Life'' example \\
10 Dec \> \> FF 99--114 \> Trees and their visitors \\
15 Dec \> HW9 due \> \> Catch up and review for final exam \\
17 Dec \> \> \> 10:30 AM--12:30 PM, Final Exam for Section 3 \\
22 Dec \> \> \> 10:30 AM--12:30 PM, Final Exam for Section 1 \\
\end{tabbing}

\pagebreak

\subsection{Schedule for Section 2}
% 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 \hskip2.5em} \=
{\bf Subject} \kill
{\bf Date(s)} \>
{\bf Assignment} \>
{\bf Reading} \>
{\hskip3em \bf Lecture Subject} \\
%
1 Sept \> HW1 \> \> Administrivia, accounts, passwords, lab use \\
       \> \> \> Objects, classes, and messages \\
8 Sept \> HW1 due\> AW 1--56 \> Software development process; design recipes \\
       \> \> \> Examples with printing, strings, and variables \\
11 Sept \> \> \> Last day to add courses \\
15 Sept \> HW2 \> AW 57--87 \> Examples with classes for input \& output \\
22 Sept \> \> \> No class: Rosh Hashanah \\
25 Sept \> \> \> Last day to drop courses \\
29 Sept \> \> \> No class: Yom Kippur \\
6 Oct \> HW2 due; HW3 \> FF 3--41 \> Defining classes, constructors, instance variables \\
      \> \> \> Inheritance, overriding, and abstract classes \\
13 Oct \> HW3 due; HW4 \> AW 89--139 \> Another view of class definition \\
20 Oct \> HW4 due; HW5 \> AW 141--187 \> How to design a class; \\
       \> \> \> numbers, literals, constants, text \\
27 Oct \> HW5 due; \> AW 189--226; \> Conditionals, booleans, and \\
\> HW6 \> FF 43--54 \> logical operators \\
30 Oct \> \> \> Last day to withdraw from classes \\
3 Nov \> HW6 due \> AW 226--263 \> Event-handling, debugging and testing \\
10 Nov \> HW7 \> AW 265--314 \> Collection classes and loops \\
17 Nov \> HW7 due; HW8 \> AW 315--377 \> Loops and Threads \\
24 Nov \> \> FF 57--97 \> Another kind of iteration: visitor classes \\
1 Dec \> HW8 due; HW9 \> AW 379--426 \> Vectors, searching, sorting, and
efficiency \\
8 Dec \> \> AW 427--460 \> Catch up; ``Game of Life'' example \\
15 Dec \> HW9 due \> FF 99--114 \> Visiting trees; catch up and review for final \\
22 Dec \> \> \> Final Exam at the usual time and place \\
\end{tabbing}

\end{document}


HW1: Download HTML source for two Web pages (my boilerplate and
CoalesceContinuous), modify and view them.  [Done largely in lab.]
Turn "boilerplate" into a personal Web page about you, including
title, links, styles, headers, images, etc.
Send me the modified HTML files by email, together
with comments on how they behaved.

HW2: a) Upload your personal Web page to your panther account, and make
sure it works there.
     b) Download the Buggles folder; modify BuggleCS [partly in lab]
     to draw "CS"; modify "Writing" to draw "CS" w/single buggle

HW3: 

HW4: a) Modify "Rings" to draw Olympic symbol.
     b) Encapsulate "C", "S", "1", and "7" into methods.  Use 'em.

