Course Description

Develop a feel for what programming is like, the process of program development, and
major concepts of programming: variables, datatypes, functions, parameters,
conditionals, compound datatypes like structures, lists, and arrays, and repeating
constructs such as loops and recursion. No programming experience is required.
(Learning Goals:Q; Distribution Reqs:FS)

Computers do many
of the same things people do, only faster, more accurately, and without getting
bored. So the task of programming a computer is essentially the task
of figuring out exactly how you would solve a particular problem, and
then explaining it to the computer. Unfortunately, computers are literal-minded
and completely without 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 algorithmic thinking. I
consider computer science a "liberal art" providing training in how
to think, regardless of whether you choose it as a profession.

2 Who Should
Take This Course?

This course is
intended primarily for people who have not previously studied computer
programming.
If you have previously
studied computer programming, you'll still learn things in this course,
but you might consider taking a more intensive course like
CSC 171 or 172.

CS, CMIS, and Math majors are allowed to take this course,
but it doesn't count towards those majors. It
does count towards the “Formal Science” and “Quantitative
Reasoning”
general-education requirements.
If you've never studied programming before
and are considering one of those majors,
you might want to take 160 anyway as a "warm-up", developing
good habits before taking CSC 171; you'll learn a lot, including some
things that aren't covered in 171. 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 programs of your
own, but simply want to use Web browsers and search engines,
spreadsheets, databases, word processors, etc. and perhaps write your
own Web pages, you should take CSC 170 instead.

3 Prerequisites

This course has no
prerequisites. Students are not expected to know anything about programming,
although students who have done some programming may still benefit from the course;
consult the professor. In any case, you should
know how to use e-mail and a Web browser.

Although the
course has no prerequisites, and is considered suitable for General Education
distribution requirements, it is nonetheless hard work. Lectures will not cover
everything you need in order to complete the homework assignments; you need to
read the textbook too. (And I wrote the textbook, so I know
whether you've read it!) There will be nine or ten homework assignments,
most of which will require hours of programming, either in a computer lab or at your
home computer. According to New York State guidelines, a 3-credit course should
take you about 9 hours/week: 3 hours in the classroom and 6 hours of reading,
study, and homework. If you can't
commit that much time in between your other courses, you should reconsider
taking this course.

4 What will
you learn?

This course isn't
intended to turn you into a professional programmer, ready to get a job in the
field next month; no single course can do that. It will,
however, show you many of the most important concepts
in programming and computer science, and give you a thorough, hands-on
understanding of the process of programming.
This will constitute a foundation on which you can build a
career in computer science, if you choose to go that way, and if not, at least
you'll be able to talk to computer scientists in their own language and
understand their concerns.

4.1 "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 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
accommodate likely changes in requirements. We'll study how to design such
programs.

4.2 Kinds
of Knowledge

A first
programming course is in some sense an almost impossible task. In one semester,
you'll be asked to learn several different kinds of knowledge:

How to use the computers and the software on them

The grammar, punctuation, and vocabulary of a
programming language

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

How to plan your time, and what sequence of steps to
go through, in designing, writing, testing and debugging a program

Application-specific knowledge (e.g. to write
a program that draws geometric shapes on the screen, you have to know something
about geometry.)

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

4.3 Language
and design recipes

Programming a
computer requires that, to some extent, you learn the computer's language.
Computers "understand" a lot of different languages, and the choice
of language affects how you approach programming. I've taught beginning
programming in a number of different languages -- Pascal, C++, Java -- but to
my mind most of them require spending too much class time on level-1 and
level-2 knowledge, with not enough time left for levels 3 and 4.
I prefer to teach a first course in a simple, consistent language designed
for beginning programmers, and switch to more complicated languages
like Java or C++ for the next semester after students have a firm understanding
of the concepts.

So this semester we'll work in “Beginning Student Language”, based
on an industrial-strength language named Scheme but modified for beginning
programming students. (Depending on how the semester goes,
we may get to Intermediate or Advanced Student Language by the end of the
semester.)

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

5 Texts

I've taught this
course for a number of years using the textbook How to Design Programs,
by Felleisen, Findler, Flatt, and Krishnamurthi (who also wrote the programming
platform we'll use, DrRacket).
This book is available on the Web at
http://www.ccs.neu.edu/home/matthias/HtDP2e/,
and you're welcome to use it as supplementary reading (although it
introduces some topics in a different order, e.g. numbers and
arithmetic before graphics and animation). That version isn't finished,
but the parts we'll get to (roughly chapters 1 through 4) are.
The complete first (2001) edition of How to Design Programs
is also available on the Web at
http://www.htdp.org/.

In the years between How to Design Programs
first and second editions, we developed a lot of new ideas about
how to teach this material, and Dr. Felleisen suggested that I write
my own textbook.
Picturing Programs
is based on How to Design Programs but different in several ways:
less emphasis on numbers and arithmetic, more emphasis on animated graphics,
and an overall slower pace. It's quite inexpensive, as CS textbooks go,
but I've put the
whole book on the web.

Picturing Programs was published in summer 2010,
but I'm only human, and I make mistakes (which I track on the "Errata"
section of the textbook web site).
When you find mistakes or confusing passages in the book,
please tell me! It may be worth extra credit....

You'll need to
read, on average, around 25 pages a week. 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, etc. there.

6 Support

This term we will be using Piazza
for class discussion. The system is
highly catered to getting you help fast and efficiently from classmates,
the TA, and myself. Rather than emailing questions to the teaching
staff, I encourage you to post your questions on Piazza (anonymously if
you wish); you may find that one of your classmates answers the question
before a tutor or I even see it. If you have any
problems or feedback for the developers, email team@piazza.com.

7 Grading

Most of your grade in this course is based on
programming homework assignments, many of which depend on previous ones.
If you haven't “got” homework 2, you won't be able to do
homework 3, which means you won't be able to do homework 3, and so on.
The moral of the story is don't get behind! As soon as
you realize you're having trouble, ask for help immediately,
whether from Piazza, the professor, or the tutor.

I expect to give
nine or ten homework assignments, each due a week or two after it is
assigned. Each homework assignment will be worth about 5-7% of your
semester grade.
Most assignments are to be written in
two-person teams (see Pair Programming, below).
In order to get your grades back more quickly,
I may not grade all the parts of a
given assignment; the un-graded parts are practice.

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. Homework
assignments will be accepted late, with a penalty of 25\% per 24 hours
or portion thereof after they're due. An hour late is 25\% off, 25
hours late is 50\% off, \emph{etc.} If you've got the choice between
turning in an incomplete program today and a better one tomorrow,
turn it in today unless you think you'll improve it by more than 25%.
Any homework assignment turned in more than four days late will get a zero
(but you should still do it, as the following assignment may depend on it).
Any homework assignment turned
in after May 8 (the last day of class) will get a zero.
(This is so I have, perhaps, time to grade them before the final exam.)

I also plan a
brief in-class quiz (say, 10 minutes each) every week or two, mostly on
level-2
language issues. Which I said I wasn't particularly interested in, but you 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
3% 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.

We'll also have a
two-hour final exam Monday, May 13 from 3:30-5:30 PM,
worth 15-20% of your semester
grade, and a "brownie points" grade, worth about 5% of your semester
grade. 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. Exams not taken without one of the above excuses will be
recorded with a grade of 0.

8 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 test cases, so I can see how it actually works. 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 cases at all will
lose 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 detailed 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 partial credit. Note that "how the program
fails" does not mean saying "I got an error message":
you need to tell me which error message you got, when you saw
it, and what you think the error message means. Similarly, if the
program fails by producing wrong answers, you need to tell me when it
produces wrong answers (are they all wrong, or just in a few cases?), how
they are wrong (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 how
such an error might have arisen.

I ask 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 fix the problem,
which is much better than turning it in incomplete.

I also expect you
to maintain a log of what kinds of errors you encountered, how you discovered
them, how long it took you to fix them, and what the actual problem was. This
log must be turned in with each homework assignment. I've written some
Web-based forms to make it easy to record this stuff, or you may just keep
track of it yourself on paper or in a text file.

Most homework
assignments in this course involve writing, testing, and debugging one or more
programs. For most of these assignments, you are to work in teams of two
students, switching teams from one
assignment to the next, if at all possible. (If you have a really terrible
schedule and can't get together with a partner, talk to me and we'll arrange
something.)

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 both students
working together on all of the assignment, using the
techniques of Pair Programming
(on which I'll give you a reading assignment). I
expect people to switch partners from one assignment to the next, so you get
experience working with different people. If you do more than three assignments with the same partner, I'll start
reducing your homework grades.

10 Ethics

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 define-struct?", etc.),
regardless of whether they're on the same team, but designing, coding, testing,
and debugging should be done by the one or two people whose names are on the
assignment. In particular, don't copy significant amounts of code from
anybody but your current partner.

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%. I don't
try to figure out who copied from whom; it is your responsibility to
not let anyone copy your homework. Among other things, that means don't leave
it on the "Universal Share" drive, because anyone at Adelphi can copy
it and even delete it.

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, both students will be penalized; see
above.

11 Schedule

This class meets
every Monday and Wednesday from 2:25-3:40 PM in Swirbul 101.

All dates in the
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 vice versa, the schedule will shift. I'll try to keep
this information up to date on the class Web page.

Lectures can be really boring, and I'd like to avoid
them wherever possible. Especially since I wrote the textbook: most
of the things I would want to say in a “lecture” are already in the
textbook, so if you've read the relevant section of the book, you don't
need a lecture. In my ideal world, you would come to class having
already read the chapter, and our in-person meetings would be asking
and answering questions and figuring out how to solve problems.
That sounds like a lot more fun than lectures.
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, every time you read about a new
programming idea, try it! Both textbooks contains lots of exercises,
which you are encouraged to do as you come to them in the text, whether
assigned as homework or not.