In brief, each hand washes the other. On one hand, the best predictor of student success in college computer science courses is success in high school algebra. The two fields share a lot of the same concepts -- variables, operators, nested expressions, functions, domains, ranges, function composition. On the other hand, computers provide a more concrete (and, for many students, more fun) way to illustrate these mathematical concepts than the blackboard.
The same design recipes that help students translate a problem description into a working program, with minor modifications, help students translate a word problem into algebraic form. But students can all too easily tell themselves that things like variables and functions are "unreal", the product of their instructor's fevered imagination; it's harder to dismiss variables and functions as "unreal" when you watch them working right in front of you.
We can use Scheme to teach many of the New York Regents "key ideas" for K-12 mathematics.
One day in September, I was talking to a late-added student after class, trying to catch her up with her classmates. I wrote the expression "3 + 4 * 5" on the board and asked what its value was. She confidently answered "35", so we talked about order of operations and how to evaluate complex algebraic expressions, illustrating the difference between (3+4) * 5 and 3 + (4*5) with Scheme expressions that she could watch the computer evaluate, one step at a time. I watched light bulbs go on over her head as she exclaimed "I could use Scheme to help with my math homework!" She had a lot of catching up to do, but she earned a B for the semester.
I've done a statistical analysis of the past three years' freshman CS classes at Adelphi. To nobody's surprise, computer science majors are disproportionately male, and computer science majors get better grades in CS courses. But when I switched the beginning language to Scheme, the correlation between gender and first-semester grade dropped sharply, almost to zero. I'm waiting on more data to assess the significance of this; I speculate that it may have to do with an increased emphasis on thinking creatively, and less on memorizing vocabulary and syntax.
The TeachScheme! Project comprises several components:
The conceptual core of the project is the design recipes: they can in principle be taught without the text, or without the DrScheme platform, or even without Scheme. For example, I translated many of the design recipes to Java for a freshman class three years ago. But the four components support one another: in particular, it's much easier to teach principled, methodical design recipes with a language that doesn't get in the way.
A first programming class is not about learning a programming language; it's about solving problems algorithmically.From this perspective, any computer language is a necessary evil: necessary in order to write real programs that really run on real computers, but evil insofar as it distracts students from thinking about problem-solving. In 1998-99, when I taught beginning programming in Java, I felt that every time I wanted to introduce a new programming principle, I had to waste a day or more of precious class time on semicolons, curly-braces, menu selections, and dialogue boxes before the students could put the principle into practice. So I add two corollaries:
Introduce only those language constructs that are necessary to teach programming principles.In my first-semester programming course, I teach perhaps half a dozen syntax rules, one at a time. That's fewer than it would take to write the simplest "hello, world!" program in C++, C, or Java, yet by the end of the semester my students are writing recursive functions, traversing linked lists, binary and n-ary trees, and writing functions that operate on other functions as parameters.Choose a language with as few language constructs as possible, and one in which they can be introduced one at a time.
But don't take my word for it. Read what other high- and middle-school teachers have said about the approach.