Contents - Cultural View

TeachScheme! 295
• a function definition for create-image, which is a one-line function in mathematics, assuming an algebra of
images with place-image, circle, and empty-scene have been introduced;
• two abbreviations, where names are equated with some value, just as in "let x be 5" in an algebra text; and
• one line for running the program.
A teacher can explain create-image as easily as any ordinary function in an algebra course. For example, one can
first draw a table with two rows and n columns where each column contains t at the top and an appropriate image at
the bottom. That is, if the numbers increase from left to right, then on each image the red dot is a little bit lower.
Finally the animate line applies the given function, create-image, at the rate of 28 ticks per second to 0, 1, 2, 3, and
so on. The resulting images are displayed on the computer monitor at the same pace. That's how movies are made.
The background needed for such an example is little more than knowledge about making movies, about the algebra
of pictures in DrRacket (which is like the one for numbers), and minimal pre-algebra. The TeachScheme! project
claims, however, that children would have more fun with such "live" functions than with algebraic expressions that
count the number of garden tiles [see Prentice Hall books for grades 8-9].
The TeachScheme! project proposes that both traditional mathematics as well as science courses could benefit from
an integration of this form of programming. In contrast to the traditional Basic or Visual Basic blocks in such books,
a Racket program consists of as many lines as the mathematics. Moving between the mathematics and the program is
thus straightforward. Better still, the meaning of the two are the same. DrRacket's algebraic stepper can illustrate
how Racket evaluates the program as if it were a sixth or seventh grade student, step by step, using plain algebra.
Functional Programming, Computing and Design in Programming 101
For the introductory curriculum on programming, the TeachScheme! project emphasizes that courses should focus
on the role of systematic design. Even if students never program again, they should see how helpful a systematic
approach to problem solving is. This should help them whether they become programmers or doctors or journalists
or photographers. Thus, an introductory course in programming would not be perceived as a place where students
learn about the syntax of the currently fashionable (and soon-to-be-obsolete) programming languages, but a place
where they can learn something widely applicable.
The key design element of the TeachScheme! curriculum is the design recipe. It has two dimensions: the process
dimension and the data dimension.
Along the process dimension students learn that there are six steps to designing a (simple) program, before they can
run it and others can use it:
• problem analysis with the goal of describing the classes of data that go into the program and come out;
• the reformulation of the problem statement as a concise purpose statement;
• the creation of examples that illustrate the purpose statement and that serve as criteria for success;
• the organization of givens, also called a template or inventory;
• coding;
• and the creation of a test suite from examples to ensure the program works properly on small inputs.
Note that, as in test-driven development, test cases are written before coding, as part of requirements analysis, rather
than afterward as part of testing.
Almost any human endeavour can benefit from clearly understanding the problem, defining criteria for success,
analyzing the available resources/givens, developing a proposed solution, and checking it against the criteria, in that
order. A journalist, for example, benefits from a similar process: figuring out the major concepts in a story; coining a
headline; lining up examples and specific data; organizing the article about the story around the givens and how the
story unfolded; writing; and fact checking.
The data dimension can be summarized by the maxim the shape of the data determines the shape of the code and
tests. For example, if the input or output data type has three variants, a test suite should have at least one test case