TITLE: Creating Examples and Writing Programs
AUTHOR: Eugene Wallingford
DATE: September 12, 2008  5:43 PM
DESC: 
-----
BODY:
On the PLT Scheme mailing list, someone asked why
the authors of <EM>How to Design Programs</EM> do
not provide unit tests for their exercises.  The
questioner could understand not giving solutions,
but why not give the examples that the students
could use to guide their thinking.  A list member
who is not an HtDP c-author speculated that if
the authors provided unit tests then students
would not bother to implement their own.

Co-author Matthias Felleisen responded "Yes" and
added this stronger assertion:

<BLOCKQUOTE><EM>
I have come to believe that being able to make up
your own examples (inputs, outputs) is
<STRONG>the</STRONG> critical step in solving most
problems.
</EM></BLOCKQUOTE>

Writing examples is one of the essential elements
of the "design recipe" approach on which Felleisen
<EM>et al</EM>. base <EM>How to Design Programs</EM>.
The idea itself isn't new, as I'm sure the book's
authors will tell you.  Some CS teachers have been
requiring students to write test cases or test plans
for many years, and the practice is similar to what
some engineers learn to do from the start of their
education.  Heck, test-driven design has gone from
being the latest rage in agile development to an
accepted (if too infrequently practiced) part of
creating software.

What HtDP and TDD do is to remind us all of the
importance of the practice and to make it an essential
step in the student's or developer's programming
process.

What struck me by Matthias's response is that making
up examples is <STRONG>the</STRONG> critical step in
writing code.  It is certainly reasonable, for so
many reasons, among them:
<UL>
<LI> It forces the programmer to write down her
     understanding of the problem in a concrete
     way early in the process.  Concrete
     understanding is always preferable to the
     fuzzy-minded understanding that follows
     reading a problem statement.  Besides,
     writing a program requires that level of
     understanding.  </LI>
<BR/>
<LI> Having examples in hand gives the programmer a
     way of talking to the client or teacher to see
     if her understanding matches that of the person
     who "owns" the problem.   </LI>
<BR/>
<LI> It gives the programmer a way of knowing how
     much code to write and so when to stop.  Most
     students can use that guidance.  </LI>
</UL>

I usually give my students several examples as a
part of specifying problems and ask them to write a
few of their own.  Most don't do much on their own
and, uncharacteristically, I don't hold them accountable
often enough.  My next programming assignment may
look different from the previous ones; I have an idea
of how to sneak this little bit of design recipe
thinking into the process.
-----