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 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 computational thinking. I consider computer science a "liberal art" providing training in how to think, regardless of whether you choose it as a profession.
Since it's an Education course, we'll frequently take breaks from learning to program and discuss how we would present our students with the material we've just learned. For example, we'll discuss how to use the "design recipes" discussed in the course as a guide for Socratic teaching and as a grading rubric.
Some of you will end up teaching computer programming as an end in itself. Some will find yourselves using computer programming as a tool to teach mathematical or scientific concepts. Some will never teach computer programming at all, but only use it for your own purposes.
Some of you have never written a computer program before; you'll experience the process of learning to program in the same way your students will. Some of you have taken one or more courses in computer programming before; you'll still learn things from this course, which takes a very different approach from what you've probably done before. You'll gain a different perspective on what you've done before; you'll see powerful concepts (e.g. higher-order functions) that you probably haven't seen in a previous programming course; you'll learn problem-solving strategies that will help you and your students regardless of language or approach; and you may even un-learn some bad habits.
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 will 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, it is nonetheless intense, hard work. The course meets as a five-day, eight-hour-a-day workshop, which doesn't leave much time for homework or studying, but I expect you to participate actively in class, discuss problem solutions with your neighbors, show me your completed problem solutions, and contribute your thoughts and insights on pedagogy and curriculum.
This course isn't intended to turn you into a professional programmer; no single course can do that. Likewise, no single course can teach you enough about programming to enable you to teach it really well. However, this course will show you many of the most important concepts in programming and computer science, develop some of the habits of a good programmer, and provide you with a variety of curricular materials you can use in your own classroom.
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, a beginning programming student is asked to acquire several different kinds of knowledge:
It is easy for a student (or an instructor 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 in a few years. 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.
There are a lot of different approaches to teaching beginning computer programming. This workshop teaches one called Program By Design, formerly known as "TeachScheme!", which has been remarkably successful with ages ranging from middle school through college, at institutions ranging from inner-city schools with lots of low-income, "at-risk" students through elite prep schools, liberal-arts colleges, and research Universities. The "Program By Design" curriculum also won its originator, Matthias Felleisen, the two highest awards in computer science education: the ACM Karlstrom award (in 2009) and the SIGCSE Outstanding Contribution to CS Education award (in 2011).
This curriculum is more explicit than most about problem-solving strategies (see "Design Recipes" below). Among other things, it incorporates the common industry practice of "test-driven design" into the first programming course. The emphasis on test cases not only gives students good long-term habits of program testing but immediately helps them understand their assignments and write their programs.
Writing test cases is much easier in a functional programming style than an imperative one (functions take arguments and return results rather than causing side effects), so we teach the functional style first before adding imperative features. As a fringe benefit, this functional style is much more compatible with mathematics than is the imperative style of programming (what does "let x = x+1" mean to a mathematician?), so Program By Design often appears in math classrooms.
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, etc. -- 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 in this course, we start in a pedagogically-designed subset of the Racket language (related to Scheme and Lisp). After students have a firm understanding of the basic concepts and habits of programming, we switch to more complicated languages like Java, C++, or Python. This transition can be tricky, though: many students take the change of language as an indication that they can forget all the good habits they learned in the first language. To avoid this, we have to make very explicit the connections between Racket concepts and those in a second language. In this workshop, we'll probably spend Day 5 discussing this transition to a second language.
We'll pay a lot of attention to step-by-step design 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, I use the design recipes as a rubric, giving a set number of points for each step in the recipe: a student can sometimes get 50% or more credit without writing any working code, just by doing a really good analysis of the problem.
I taught a beginning computer programming course for 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 for free.
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 that has made it popular among high school teachers. 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....
The Second Edition of How to Design Programs hasn't been finished yet, but the current version is on the Web for free. It does more graphics and animation than the first edition, uses more numbers and arithmetic than Picturing Programs, and goes faster than either.
We'll use the free, open-source programming environment DrRacket for this workshop, and I encourage using it for your own classes.
We'll be using Piazza for discussion outside the classroom (including before and after the workshop). The system is designed to get 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 the teaching staff even see it. If you have any problems or feedback for the developers, email team@piazza.com.
For those of you taking this workshop for a grade, your grade will be based on class participation and on programming problems you solve and turn in. There is no final exam. If you wish, you may do some of the problems in partnership with another student; if so, put both names on the program and turn it in once.
The Adelphi University Code of Ethics applies to this course; look it up on the Web at http://academics.adelphi.edu/policies/ethics.php .