[plt-scheme] HTDP 12.4.2

LOL. Ok I've been rumbled.
I'll start all over again the way I've been told and await the light bulb 
moment.


----Original Message Follows----
From: Stephen Bloch <sbloch at adelphi.edu>
To: "wooks wooks" <wookiz at hotmail.com>, plt-scheme at list.cs.brown.edu
Subject: Re: [plt-scheme] HTDP 12.4.2
Date: Wed, 21 Jun 2006 23:26:14 -0400

At 1:03 AM +0100 6/22/06, wooks wooks wrote:
[code snipped]

This is remarkably similar to the code one of my sharpest students came up 
with for this problem last year (except that he was more careful with the 
contracts, so his worked :-))  I'll tell you the same thing I told him: 
you're thinking too hard.  Follow the design recipe... really!

When I first saw the HtDP design recipe in a TeachScheme! workshop c. 1999, 
I thought "These folks have some good ideas, but this 'design recipe' is 
just too dumb for words."  Since then I've taught maybe a dozen courses 
using it, and every semester has convinced me more of its usefulness -- not 
just for the weak, confused, struggling students but for the "sharp" ones 
too.  Almost every semester there's at least one sharp student who skips the 
design recipe and gets through the assignments on brilliance... until 
usually around Chapter 12, this student who has never asked for help on 
anything all semester shows up at my office door with a program that's 
getting more and more complicated and no closer to working.  As soon as it 
becomes clear to me that the student hasn't followed the design recipe at 
all, I throw out the existing code and start from scratch, asking questions 
to lead him (it's almost always "him") through the design recipe.  Half an 
hour later the student walks out with a correct, working, clear program half 
as long as the incorrect, confusing one he walked in with.

As Danny pointed out, your contract for "insertEverywhere" doesn't match the 
way it is used in "arrangements".  This would be clearer to you if you took 
the test cases seriously: start with the empty case, then a one-element 
list, then a two- or three-element list, each one accompanied with what the 
correct answer should be.  Writing these test cases, with correct answers, 
is not just a way of conveniently testing the program once it's written; 
it's a way of clarifying your understanding of what the program is supposed 
to do.  That's why you do it BEFORE writing the program (you do, don't you?)

If one of my students turned this in, (s)he would lose points for
(a) getting the contract for "insertEverywhere" wrong
(b) not providing ANY test cases for "insertEverywhere" (there should be at 
least two or three, including an empty one)
(c) not explaining what "infiltrate" is supposed to do (I don't require 
purpose statements for the assigned functions, or for functions whose names 
are self-explanatory, but "infiltrate" isn't)
(d) not providing an empty test case for "infiltrate"
(e) not providing the correct answers for each test case for "infiltrate"
and, of course (f) a program that doesn't produce right answers :-)
Every one of these items is not just Dr. Bloch being mean and picky; these 
are practices that will HELP YOU PRODUCE CORRECT PROGRAMS.
--
					Stephen Bloch
					sbloch at adelphi.edu