[plt-scheme] HTDP 12.4.2

On Jun 21, 2006, at 11:43 PM, wooks wooks wrote:

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

Try harder: it is not about the "light bulb" at all. Unless you speak 
of the necessity to buckle under and to understand "programming as the 
discipline of design" as the "light bulb."

We, the CS people, are the essence of design (and I don't mean HCI) but 
so much of what is sold as CS is complete total BS. We could do so much 
better

-- Matthias





>
>
> ----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
>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme