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.
This course is intended primarily for people who have not previously studied computer programming, especially non-CS-majors. For non-majors, this course counts towards your math/science distribution requirement. If you have previously studied computer programming, you'll still learn things in this course, but you might be better served by taking a more intensive course like CSC 171 or 172.
If you're a math, computer science or information systems major or minor, this course will not count towards the major/minor. However, if you've never studied programming before, or if you're considering one of those majors, you might want to take it 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.
This course has no prerequisites. Students are not expected to know anything about programming, although students who have done some programming in a different language may still benefit from the course; consult the professor. In any case, it would be helpful if you knew 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. 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 consider postponing this course to next semester.
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.
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.
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:
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.
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. So I prefer to start students in the simple, consistent, easy-to-use Scheme language, and switch to more complicated languages like Java or C++ for the next semester after students have a firm understanding of the concepts.
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.
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.htdp.org/, and you're welcome to use it as supplementary reading (although some sections are out of date and may be confusing).
In the years since How to Design Programs was published, we've developed a lot of new ideas about how to teach this material, so I wrote my own textbook, Picturing Programs, 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. Please don't waste paper by printing it all out....
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 30 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.
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 Nick or I even see it. If you have any problems or feedback for the developers, email team@piazza.com.
I expect to give seven to nine homework assignments, each due a week or two after it is assigned. 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. Assignments will lose 10% credit per day late, so 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 10%. Any homework assignment turned in after midnight, Dec 8 (the last day of class) will get a zero. Each homework assignment is worth about 5-6% of your semester grade.
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 INSERT TIME AND DATE HERE, 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.
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.
The Adelphi University Code of Ethics applies to this course; look it up on the Web at http://academics.adelphi.edu/policies/ethics.php .
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.
This class meets every Tuesday and Thursday from 12:15-1:30 in Science 227.
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.
I expect you to have read the reading assignments (usually 15 pages per lecture) 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. 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.
I'll try to keep an up-to-date schedule on the Web at http://www.adelphi.edu/sbloch/class/160/calendar.shtml .