On Jun 27, 2012, at 6:39 AM, m...@goblin.punk.net wrote: > I am planning to work through _How to Design Programs_ but > already have some (imperative) programming experience as well as > some exposure to Racket/Scheme. > > I found the following piece of advice in the mailing list > archive. Any updates or other tips? > > http://groups.google.com/group/plt-scheme/msg/167c9643e187d265
That piece of advice ends with "avoid draw.ss exercises and use world.ss instead. However, this is a nontrivial shift." If you're using _How to Design Programs, 2nd edition_, this shift is already made for you. I've taught functional programming in Racket/Scheme to a number of students who already had imperative programming experience, and they often make problems much harder and more complicated than they need to be. For example, when asked to do something to each of the items in a list, they'll find the length of the list, initialize a numeric variable to 0, initialize another variable to a "default" result, then try to loop over the list, doing a "list-ref" and modifying both of these variables each time. You can do that, but it's not idiomatic functional-programming style, and the resulting code is about three times as long and substantially slower than if you did it in a more functional style. Which is why the beginning and intermediate student languages in DrRacket don't ALLOW you to modify an already-defined variable: sure, a professional programmer will occasionally need to do this, but you'd be amazed at how much sophisticated programming you can do without assignment statements. The design recipe is key. When Matthias first showed it to me in 1999, I thought "this is too dumb for words," but it's really incredibly helpful. Especially the part about writing test cases before you start writing the code: whenever you find yourself falling into an imperative morass like that in the previous paragraph, just stop and write down several examples of calling the function, together with their correct answers. This enables you to focus on the relationship between arguments and results, rather than on a particular imperative algorithm for getting from the former to the latter, and you may well find that with this revised focus, the "algorithm" becomes almost trivial. I was at a CS pedagogy conference last year and mentioned this test-driven design technique to my roommate, a colleague from another school. My colleague said "Well, that's great for a software engineering course, but these are freshmen; they're not ready for test-driven design yet." I replied "No, you've got it backwards: the students in your software engineering course MIGHT be sharp enough and experienced enough to sometimes do without test-driven design; the freshmen are the ones who need it the most." I might have added "freshmen -- and people who already know imperative programming" :-) Stephen Bloch sbl...@adelphi.edu
____________________ Racket Users list: http://lists.racket-lang.org/users
