Re: [Caml-list] Re: Re: Teaching bottomline, part 3: what should improve.

[Robert C Fischer <robert@fischerventure.com>]

I actually did something like this back in my CSci education.  We would 
debug programs by isolating the buggy code, then having each student be 
one expression in the code, and walk through the program having each 
person perform their little function.  Of course, you got "swapped out" 
if you failed to perform your expression right -- it was surprisingly 
fun and provided a nice way to visualize things going on in an otherwise 
abstract system.

~~ Robert.

Pal-Kristian Engstad wrote:
> Vincent Aravantinos wrote:
>> Those are typically the comments of a 
>> "used-to-functional-programming" guy.
>> It certainly doesn't match what a beginner would think (no beginner 
>> will call a
>> function a "value").
> This reminds me of a "game" I used to teach my math students the 
> concept of a function. I think it should be able to be used for an 
> introductory computer science class as well.
>
> Essentially, the game involves having person A come up with a rule. 
> Person B will have to provide an input value, and A has to faithfully 
> give the result of the rule/computation. Examples of functions could 
> be \x->x+2, \x->2*x, etc. More interesting examples involves the 
> function that returns the first letter of the name of the input (f 
> "one" = "o"), or the successor of a "red, yellow, green" traffic light 
> symbol.
>
> When doing this, A and B will quickly have to agree on the allowed 
> input values (the domain) and in order to have a chance it is also 
> helpful if B knows the range of output values (the image). And for 
> sure - they will have to agree that the rule x = y => f(x) = f(y) has 
> to hold in order to be able to guess what "f" is. [I would also 
> disallow closures for this game - otherwise it would be too hard to 
> guess.]
>
> The reason this exercise is good is that it teaches the students (in a 
> fun way) the important concepts behind a function. It will make them 
> understand that a function is just a computation, but also point out 
> the importance of defining the types (sets) of inputs and outputs. I 
> think that after playing this game, you can venture to talk about the 
> "name" of the function, and they will realize that it does not matter 
> what the name of the function is - just what it does.
>
> Perhaps after this, you can teach the concept of treating a function 
> as a value, or input to another function? Person A makes a function 
> that takes person B's function, etc.
>
> Thanks,
>
> PKE
>