Computers obviously not harmful (was: Re: [plt-scheme] Computers considered harmful)

From: John Clements (clements at brinckerhoff.org)
Date: Mon May 11 14:27:32 EDT 2009

On May 11, 2009, at 10:56 AM, Joe Marshall wrote:

> On Mon, May 11, 2009 at 10:10 AM, John Clements
> <clements at brinckerhoff.org> wrote:
>>
>> Yes, I'm imagining it: the solution is still going to look  
>> imperative,
>> right?
>>
>> e.g.:
>>
>> (define (react state)
>>  (cond [(empty-sensor? state) (return counter)]
>>        [else (set counter (+ counter 1)) (move-to-cdr)]))
>>
>> It appears to me that applying the "robot model" to introductory  
>> programming
>> is not going to help you make the crucial bridge to algebraic  
>> programming.
>
> The substitution model is going to be a problem in `the real world'  
> because
> you can't readily replicate objects.
>
> On the other hand, consider something like this
> (map 1+ list-of-numbers)
>
> (define (map f l)
>  (cond ((pair? l) (cons (f (car l)) (map f (cdr l))))
>           ((null? l) '())
>           (else (error))))
>
> You are still applying F one element at a time.  There is a single
> sequential locus of execution.  You don't have the side effect problem
> though because you have new cons cells all along the way.
> So maybe your robot has to do this:
>
> (define (react state)
>  (cond [(empty-sensor? state) (return counter)]
>           [else (get-new-counter (+ counter 1)) (move-to-cdr)]))
>
> Where the act of `getting a new counter' doesn't cause a side effect
> any more than cons does.

Sorry, I lost track of my original "add one to each element of a list"  
plan, and changed it into a simple 'count'.  Actually, the map 1+ is a  
much better example.  I claim that the little robot is going to have  
to zip down the list, and then make fresh cons cells as it travels  
back up, "remembering" all the time where the prior input cons cell  
was.. that is, what the "stack" looks like.  I think that this is

a) the way that many intro students *do* think about the map  
operation, and
b) vastly and needlessly more complex than the simple HtDP-style  
formulation of add1-map.

I think my claim is perhaps less bold than it appears; I'm simply  
claiming that you want to build HtDP-style programming on top of the  
students' mathematical foundations, rather than on their robotic/ 
imperative foundations.

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2484 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20090511/f0504258/attachment.p7s>

Posted on the users mailing list.