Re: Re: Teaching bottomline, part 3: what should improve.

Re: Re: Teaching bottomline, part 3: what should improve.

[Vincent Aravantinos]

On Wed, 23 May 2007, Loup Vaillant wrote :

> (...)

>> * Anonymous functions are still beyond most of them.
>
> That sounds surprising, for anonymous function are no different  
> from named ones:
>
> 5;; (* a value *)
> fun x -> x+1;; (* another value, which happens to be a function *)

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").

Or do you really think that seeing functions as first-class object is  
the natural way ?
IMHO this is not the case, and therefore not the case of a beginner.

To my eyes, there are (I mean, "in human mind" or at least in an  
ocaml beginner's mind)
values AND functions. A function turns into a value (in the mind of  
the programmer)
only when it is used by a higher order function.

> a = 5;; (* a bound value *)
> b = fun x -> x+1;; (* another bound value, which happens to be a  
> function *)
>
> Did your students used map and fold-like functions much? These almost
> require anonymous functions.

Indeed, using map and fold puts the focus on the fact that functions  
_can_ be values.
Thus their importance in a pedagogical context.

Maybe all this is just a matter of belief...

Regards,
Vincent

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

[Loup Vaillant]

2007/5/23, Vincent Aravantinos <vincent.aravantinos@yahoo.fr>:
> On Wed, 23 May 2007, Loup Vaillant wrote :
>
> > (...)
>
> >> * Anonymous functions are still beyond most of them.
> >
> > That sounds surprising, for anonymous function are no different
> > from named ones:
> >
> > 5;; (* a value *)
> > fun x -> x+1;; (* another value, which happens to be a function *)
>
> 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").

You are quite right. My point was to find a way to tell the beginners.
A way to stress upon the fact that functions are values like any other
(in Ocaml, at the very least).

I see some difficulties, thought :

First, the syntax:
b = fun x -> x+1;; (* b defined as a functionnal value *)
b x = x+1;; (* b defined as a mere function *)

Second, imperative languages, where b can only be defined as a mere
function. Many courses begin with an imperative language.

Third, high school, where the only functions we dare name as such are
of type number -> number. Derivation and composition, for instance,
are named "operations", not functions. As if they have anything
special (usefulness excepted). Finally, each function has a name in
high shool mathematics.


> Or do you really think that seeing functions as first-class object is
> the natural way ?
> IMHO this is not the case, and therefore not the case of a beginner.

I agree. I just hope it can become A natural way.

> To my eyes, there are (I mean, "in human mind" or at least in an
> ocaml beginner's mind)
> values AND functions. A function turns into a value (in the mind of
> the programmer)
> only when it is used by a higher order function.

I think there are some other uses, too : data structures can contain
closures for instance. A lazily evaluated value is a function (a
closure).


> > Did your students used map and fold-like functions much? These almost
> > require anonymous functions.
>
> Indeed, using map and fold puts the focus on the fact that functions
> _can_ be values.
> Thus their importance in a pedagogical context.

Not only : most loops in a list or an array can be expressed as a
combination of map and fold (and filter, and...). Using these
significantly reduce the amount of code.

> Maybe all this is just a matter of belief...

I am quite a zeelot of abstraction. :)

Regards,
Loup

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

[Pal-Kristian Engstad]

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

-- 
Pål-Kristian Engstad (engstad@naughtydog.com), Lead Graphics & Engine Programmer,  
"Uncharted"-team, Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.

"Most of us would do well to remember that there is a reason Carmack
is Carmack, and we are not Carmack.",
                       Jonathan Blow, 2/1/2006, GD Algo Mailing List

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

[Pal-Kristian Engstad]

Sorry, I forgot to mention the point of the game. Person B is supposed 
to figure out what function person A is using.

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
>

-- 
Pål-Kristian Engstad (engstad@naughtydog.com), Lead Graphics & Engine Programmer,  
"Uncharted"-team, Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.

"Most of us would do well to remember that there is a reason Carmack
is Carmack, and we are not Carmack.",
                       Jonathan Blow, 2/1/2006, GD Algo Mailing List

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

[Robert C Fischer]

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
>

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

[Vincent Aravantinos]

> Date: Wed, 23 May 2007 15:21:55 +0200
> From: "Loup Vaillant" <loup.vaillant@gmail.com>
> Subject: Re: [Caml-list] Re: Re: Teaching bottomline,	part 3: what
> 	should improve.
>
> 2007/5/23, Vincent Aravantinos <vincent.aravantinos@yahoo.fr>:
>> On Wed, 23 May 2007, Loup Vaillant wrote :
>>
>>> (...)
>>
>>>> * Anonymous functions are still beyond most of them.
>>>
>>> That sounds surprising, for anonymous function are no different
>>> from named ones:
>>>
>>> 5;; (* a value *)
>>> fun x -> x+1;; (* another value, which happens to be a function *)
>>
>> 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").
>
> You are quite right. My point was to find a way to tell the beginners.
> A way to stress upon the fact that functions are values like any other
> (in Ocaml, at the very least).
>
> I see some difficulties, thought :
>
> First, the syntax:
> b = fun x -> x+1;; (* b defined as a functionnal value *)
> b x = x+1;; (* b defined as a mere function *)
>
> Second, imperative languages, where b can only be defined as a mere
> function. Many courses begin with an imperative language.
>
> Third, high school, where the only functions we dare name as such are
> of type number -> number. Derivation and composition, for instance,
> are named "operations", not functions. As if they have anything
> special (usefulness excepted). Finally, each function has a name in
> high shool mathematics.
>
>
>> Or do you really think that seeing functions as first-class object is
>> the natural way ?
>> IMHO this is not the case, and therefore not the case of a beginner.
>
> I agree. I just hope it can become A natural way.
>
>> To my eyes, there are (I mean, "in human mind" or at least in an
>> ocaml beginner's mind)
>> values AND functions. A function turns into a value (in the mind of
>> the programmer)
>> only when it is used by a higher order function.
>
> I think there are some other uses, too : data structures can contain
> closures for instance. A lazily evaluated value is a function (a
> closure).
>
>
>>> Did your students used map and fold-like functions much? These  
>>> almost
>>> require anonymous functions.
>>
>> Indeed, using map and fold puts the focus on the fact that functions
>> _can_ be values.
>> Thus their importance in a pedagogical context.
>
> Not only : most loops in a list or an array can be expressed as a
> combination of map and fold (and filter, and...). Using these
> significantly reduce the amount of code.
>
>> Maybe all this is just a matter of belief...
>
> I am quite a zeelot of abstraction. :)
>
> Regards,
> Loup

All agreed !

Regards,
Vincent