[plt-scheme] you have a tough road ahead of you ; ; ; was Re: from hell to paradise
On Wed, Feb 18, 2009 at 7:43 AM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> I expect that somewhere around late part II, you will slow down. You may
> pick up real reading as of part III, though some may make it thru III and
> only "stutter" in IV.
>
Is this really what you have observed or just an expectation? Part IV
(i.e. abstraction) is where my students finally bought into the
methodology. Part IV is what they considered easier, because it
clicked with them and really made sense. In addition, they felt like
they had grasped a real time-saving concept. The dialog after my first
lecture was telling and inspiring in many ways:
We had developed (this differs a little from the presentation in HtDP):
; make-filter: X --> boolean --> ((listof X) --> (listof X))
(define (make-filter pred)
(local
[; concrete-filter: ((listof X) X --> (listof X))
(define (concrete-filter L n)
(cond [(empty? L) empty]
[else (cond [(pred (first L) n) (cons (first L)
(concrete-filter (rest L)))]
[else (concrete-filter (rest L))])]))]
concrete-filter))
After that we used it defined new functions as follows:
less-than-filter: ((listof number) number --> (listof number))
(define less-than-filter (make-filter <))
; less-than-2: (listof number) --> (listof number)
(define (less-than-2 L) (less-than-filter L 2))
; less-than-5: (listof number) --> (listof number)
(define (less-than-5 L) (less-than-filter L 5))
with appropriate checks here for both less-than-2 and less-than-5.
I pointed out that now we are using functions for which we did not
explicitly write.
Upon concluding the example:
Students: [looked in awe]
Marco: [smile]
Student A: [spontaneously] Wow....you make it look like magic!
Student B: That's incredible.
Marco: Is it really magic?
Student C: No, it only looks like magic.
My students found developing functions that take more than one
compound value as input much harder than all of Part IV.
--
Cheers,
Marco