Re: explaining functions [Possibly OT]

I've always thought of the mathematical and programming notions of functions to be very different things. The problem with the mathematical definition of a function is that it is that it isn't broad enough, e.g. it says nothing about side-effects like printing, making a sound, or reading/writing a file, etc. So I think defining functions as "black boxes" or little machines is the way to go ... I think it's a mistake to explain Python functions as being the same sort of thing as mathematical functions. My experience is that the average student usually has no trouble understanding how to use a function. They grasp the mechanics pretty quickly from examples. Issues such as the difference between printing a result and returning a result are confusing to some, as are issues such as scope. But you don't need to have a perfect understanding of such things to use functions effectively. By far the biggest difficulty I've seen students have is deciding how and when to make their own functions. This is exacerbated by the fact that in beginning programming you typically only write small programs where writing your own functions might not be useful. Toby
Hi all,
This might be a bit tangential to the topic; if so, my apologies. (I've been reading this list for a while, but have never posted before.)
I'm a Python hobbyist, and am not involved in CS education, except peripherally. I am also a grad student in Philosophy who has, for a few years now, been teaching Introduction to Formal Logic to audiences largely composed of Philosophy and Linguistics undergrads with a small contingent of Computer Science undergraduates, too.
I have found it difficult to get some of the humanities undergraduates to see the understand the general mathematical concept of a function. Occasionally, even some of the CS students (who, when I see them, have just begun) stumble with the concept, too.
The best I have managed to come up with is to tell them that a function is like a 'black box' to which you feed some ordered input of the appropriate sort, and it gives you an output determined entirely by that input.
I have found that, at least for the humanities students, getting them to understand some of the material is largely a matter of finding a useful metaphor (and, convincing them that the metaphor is an aid, not the thing in itself). That's been the only way to get the ones bothered by the mathematician's use of "if ... then ..." to accept it. (They don't like that "If 2 + 2 = 97 then I am King of the moon" and "If grass is green then sky is blue" are taken to be true.)
So, I am wondering if others on the list have had difficulty getting students (particularly students not primarily studying Math or CS) to get the idea of a function? If so, I'd be very interested in what techniques were of use.
Thanks, and I do apologize if this query is received as too peripherally related to the topic of the list. Best to all,
Brian vdB

Toby Donaldson wrote:
My experience is that the average student usually has no trouble understanding how to use a function. They grasp the mechanics pretty quickly from examples. Issues such as the difference between printing a result and returning a result are confusing to some, as are issues such as scope. But you don't need to have a perfect understanding of such things to use functions effectively.
I didn't have a chance to test the following on students but I think the Python interpreter offers a chance to postpone the print/return difference by just not teaching "print" (except parhaps as a debugging aid). A "hello world" program should be just:: >>> "Hello, world!" I think that introducing arguments and return values is much simpler to understand than textual input/output usually taught with languages that lack a convenient interpreter prompt.
By far the biggest difficulty I've seen students have is deciding how and when to make their own functions. This is exacerbated by the fact that in beginning programming you typically only write small programs where writing your own functions might not be useful.
Writing only small programs is harmful. Students must get the chance to write medium programs and to refactor them a lot. I think that any attempt at teaching good style and structure by "here is how you should write" is futile. Only by experiencing the hard way how is it to program without good structure will one learn its importance. -- Beni Cherniavsky <cben@users.sf.net>, who can only read email on weekends.

Beni Cherniavsky said: <snip>
By far the biggest difficulty I've seen students have is deciding how and when to make their own functions. This is exacerbated by the fact that in beginning programming you typically only write small programs where writing your own functions might not be useful.
Writing only small programs is harmful. Students must get the chance to write medium programs and to refactor them a lot. I think that any attempt at teaching good style and structure by "here is how you should write" is futile. Only by experiencing the hard way how is it to program without good structure will one learn its importance.
I agree with this basic assessment. However it is also true that students won't necessarily just "stumble" on good ways of (re)organizing programs. They probably need to see/write a couple programs in the "here is how you should write" mold before the hard lessons of experience will be really sucessful in internalizing this knowledge. --John -- John M. Zelle, Ph.D. Professor of Computer Science Wartburg College

Writing only small programs is harmful. Students must get the chance to write medium programs and to refactor them a lot. I think that any attempt at teaching good style and structure by "here is how you should write" is futile. Only by experiencing the hard way how is it to program without good structure will one learn its importance.
-- Beni Cherniavsky <cben@users.sf.net>, who can only read email on weekends.
My approach is the same one used by other language teachers (e.g. of Spanish or Japanese): don't just focus on writing the stuff; read it also. And what you read may be quite a few notches ahead, in terms of level. It's easier to read that to write. So, for example, with my Povray scene description language generator, I don't have time to take students through reinventing that wheel. I spring it on them full-blown, if simplified (my complicated versions aren't so easy to grasp). They read it for comprehension, and as their coding skills improve, it also becomes a place to take off from, i.e. they're able to modify and add features. This is true-to-life in open source work: the first big programs you refactor and/or modify in some way, were probably written by others. Kirby
participants (4)
-
Beni Cherniavsky
-
John M. Zelle
-
Kirby Urner
-
Toby Donaldson