4 ms·

I'm not sure about your teaching experience. But when i teach function, i told my students: Function application is just substitution. That's it. Function is a

I'm not sure about your teaching experience. But when i teach function, i told my students: Function application is just substitution. That's it. Function is a template for you to substitue. Higher order function ? Just more substitution ! Your source code is a long text template, no magic to it.

throwaway744678 4y ago
You're describing macros, leaving out (rather important) things, such as scoping.
threatofrain 4y ago
I teach the concept of a procedure since that's how functions are in most programming languages but I also emphasize the concept of a mathematical function. The procedure perspective looks into the box whereas the functional perspective thinks more about composition than the details inside the box. 4 → square_root → triple → ? How does the square_root function work? It's an interesting question but often times assembling multiple atoms into a structure is more empowering and exciting; plus children will be using functions where the details elude them for quite awhile. Using functions with elusive details is also typical in math pedagogy so children should get used to reasoning around black boxes.
mansoon 4y ago
Siiiiidddeeeee eefffffeeeeeeecccccttttts. Would like to have a word with you.
_dain_ 4y ago
>Function application is just substitution. >Your source code is a long text template, no magic to it. No, no, no! This is wrong, and really bad pedagogy. def func_1(x): return x + x def func_2(y): print(y) return y z = func_1(func_2(5)) If function application is substitution, then a student may expect the expansion to work something like this: z = func_1(func_2(5)) z = func_2(5) + func_2(5) z = { print(5); 5 } + { print(5); 5 } # pretend python has curly braces for this to make sense so 5 would get printed twice. But in reality it only gets printed once. Doing the substitution from inside-out doesn't help either, you get the same thing: z = func_1(func_2(5)) z = func_1({ print(5); 5 }) z = { print(5); 5 } + { print(5); 5 } I've had to un-teach this mistaken idea in beginners before. It harms their understanding of the call stack, scoping rules, etc.
- lo_zamoyski 4y ago
  > Function application is just substitution. >> No, no, no! This is wrong, and really bad pedagogy. I would avoid the word "substitution" until after evaluation order has been covered. Python has applicative order evaluation like most languages. Pedagogically, since evaluation is just a basic concept, it should be explained before the student even gets to functions. Then, when you get to function application, it probably shouldn't take much more to explain that arguments are evaluated first and only then is the function applied on the evaluated values of those arguments. The values are then substituted wherever the parameter appears. If side effects weren't in the picture, you could postpone discussion of evaluation order a little bit longer until you discuss the consequences evaluation rules have for runtime complexity (using pedagogically appropriate language, of course). So you could get away with allowing inaccurate ideas about substitution for a little while.
- xigoi 4y ago
  It's unfortunate that Python calls procedures “functions”, which is mathematically wrong and leads to this mistake.
- shrimpx 4y ago
  If you’ve covered eager evaluation, the substitution analogy mostly works. What you’re showing is lazy evaluation which is an alien concept in Python land.
  - deleted 4y ago
    [deleted]
zabzonk 4y ago
have you ever looked at the code that a compiler emits, or how an iterpreter executes code?
abricq 4y ago
I rather see functions as transformations, in the mathematical sense. A function receives an input and produces an output, according to some logic that only the function is responsible for. A small logical block that can be reused into somehow bigger logical blocks (i.e. programs). I think it is much more realistic, lead you to good programming practice, and also much more fun. I have tried to teach that and students have always (seem) to like & understand this approach. It was for student at university level, so maybe more able to understand this 'functional' view of functions.
- thanatropism 4y ago
  Yes, but functions in Python are not that. Mathematical transformations don't support closures for one. Dictionaries are more like functions and indeed I taught myself to understand hashmaps as "frozen functions" way back when. You can easily find the set-valued inverse of a function by saying {v: [k for k in d.keys() if k[v]==v] for k, v in d.items()} and that's close to the mathematical definition too.
  - xigoi 4y ago
    > Mathematical transformations don't support closures for one. What? In mathematics, you often have things like “let c be a real number; let f(x) = x + c”.
int_19h 4y ago
It seems to be an intuitive way to explain it, which is probably why it found its way into the specs for some early languages. The problem is that it gets very complicated real fast once you start dealing with non-trivial expressions as arguments, shadowed identifiers, and recursion.

throwaway744678 4y ago

You're describing macros, leaving out (rather important) things, such as scoping.

threatofrain 4y ago

I teach the concept of a procedure since that's how functions are in most programming languages but I also emphasize the concept of a mathematical function. The procedure perspective looks into the box whereas the functional perspective thinks more about composition than the details inside the box. 4 → square_root → triple → ? How does the square_root function work? It's an interesting question but often times assembling multiple atoms into a structure is more empowering and exciting; plus children will be using functions where the details elude them for quite awhile. Using functions with elusive details is also typical in math pedagogy so children should get used to reasoning around black boxes.

mansoon 4y ago

Siiiiidddeeeee eefffffeeeeeeecccccttttts. Would like to have a word with you.

_dain_ 4y ago

>Function application is just substitution. >Your source code is a long text template, no magic to it. No, no, no! This is wrong, and really bad pedagogy. def func_1(x): return x + x def func_2(y): print(y) return y z = func_1(func_2(5)) If function application is substitution, then a student may expect the expansion to work something like this: z = func_1(func_2(5)) z = func_2(5) + func_2(5) z = { print(5); 5 } + { print(5); 5 } # pretend python has curly braces for this to make sense so 5 would get printed twice. But in reality it only gets printed once. Doing the substitution from inside-out doesn't help either, you get the same thing: z = func_1(func_2(5)) z = func_1({ print(5); 5 }) z = { print(5); 5 } + { print(5); 5 } I've had to un-teach this mistaken idea in beginners before. It harms their understanding of the call stack, scoping rules, etc.

lo_zamoyski 4y ago
> Function application is just substitution. >> No, no, no! This is wrong, and really bad pedagogy. I would avoid the word "substitution" until after evaluation order has been covered. Python has applicative order evaluation like most languages. Pedagogically, since evaluation is just a basic concept, it should be explained before the student even gets to functions. Then, when you get to function application, it probably shouldn't take much more to explain that arguments are evaluated first and only then is the function applied on the evaluated values of those arguments. The values are then substituted wherever the parameter appears. If side effects weren't in the picture, you could postpone discussion of evaluation order a little bit longer until you discuss the consequences evaluation rules have for runtime complexity (using pedagogically appropriate language, of course). So you could get away with allowing inaccurate ideas about substitution for a little while.
xigoi 4y ago
It's unfortunate that Python calls procedures “functions”, which is mathematically wrong and leads to this mistake.
shrimpx 4y ago
If you’ve covered eager evaluation, the substitution analogy mostly works. What you’re showing is lazy evaluation which is an alien concept in Python land.
- deleted 4y ago
  [deleted]

zabzonk 4y ago

have you ever looked at the code that a compiler emits, or how an iterpreter executes code?

abricq 4y ago

I rather see functions as transformations, in the mathematical sense. A function receives an input and produces an output, according to some logic that only the function is responsible for. A small logical block that can be reused into somehow bigger logical blocks (i.e. programs). I think it is much more realistic, lead you to good programming practice, and also much more fun. I have tried to teach that and students have always (seem) to like & understand this approach. It was for student at university level, so maybe more able to understand this 'functional' view of functions.

thanatropism 4y ago
Yes, but functions in Python are not that. Mathematical transformations don't support closures for one. Dictionaries are more like functions and indeed I taught myself to understand hashmaps as "frozen functions" way back when. You can easily find the set-valued inverse of a function by saying {v: [k for k in d.keys() if k[v]==v] for k, v in d.items()} and that's close to the mathematical definition too.
- xigoi 4y ago
  > Mathematical transformations don't support closures for one. What? In mathematics, you often have things like “let c be a real number; let f(x) = x + c”.

int_19h 4y ago

It seems to be an intuitive way to explain it, which is probably why it found its way into the specs for some early languages. The problem is that it gets very complicated real fast once you start dealing with non-trivial expressions as arguments, shadowed identifiers, and recursion.