[plt-scheme] HTDP 12.4.2

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