more on "variable names"
I filed the following quick comment after viewing a six minute tutorial on variables and values at ShowMeDo. The video: http://showmedo.com/videotutorials/video?name=6950010&fromSeriesID=695 My comment: """ idea that values are "stored into" a variable is less the metaphor in Python, which is more about assigning or binding names to objects with the assignment operator (=). The problem with "store into" is then its hard to picture many names for the same object, yet that's easy when you think of a balloon with many strings. """ Yikes it posted three times dammit, makes me the foolish dweeb. Anyway, based on our longish threads here awhile back, I think "we who consider ourselves Python teachers" should actively check ourselves against using the verbs "to store in" or "store into" with respect to objects and their top-level names. The reason is, once you picture a dog in a doghouse, with the variable name as the doghouse, then it's hard to visualize how other doghouses could contain the same dog (the same value) without there being multiple copies of the same dog (clones?). A better image is balloons on strings. I realize it's not customary to have one helium balloon with two or more strings, different hands holding each string, sharing the same balloon, but there's nothing conceptually difficult about it (feels kind of ubuntu), whereas with that dog in the doghouse... that way madness lies. As several teaching professionals were noting on this list, a Python name is a lot more like a C pointer in the sense that it neither grows nor shrinks with respect to that which it names, i.e. the "size of object" is not a name's concern (another way to break the hold of the container-contained imagery). I think when we teach low level (including but not limited to children), we actually mess with (rewire) basic associations, a common technique in pedagogy (called "mnemonics"). For example, the so-called "equal sign" (=) would be better called an "assignment operator" as most of us here do. To make this link stick we could explain how the two parallel lines represent "opening a channel to" i.e. now this name (on the left) will be able to communicate with the object on the right (some result of evaluation). Why "open a channel to"? Because now we have "dot notation" i.e. our little API "control panel" at the near end of the string, our little "interface words" (triggers, attributes, methods with args)... our "messages" (to use Smalltalky talk). We don't really want s = 3 to be read "s equals 3" in Python. It's closer to "s names 3" or "s represents 3" or even "s speaks for 3". Not "s stores 3", nor "s contains 3". Probably the idea of "garbage collection" should be introduced right at this juncture, with arched eyebrows ala Spock if we forget to mention it. That's a really good way to anchor the many-to-one strings-to-balloon metaphor, with the idea of a reference counter on the object. Dogs in doghouses don't have reference counters, plus we wouldn't want them garbage collected. Balloons, on the other hand, go pop, which'd be a convenient way to represent "freeing up memory". Kirby PS: do Python's where Prada? http://fashionshops.wordpress.com/2009/05/18/prada-ad-campaign-ss-2009/
On Sat, May 23, 2009 at 7:43 PM, kirby urner <kirby.urner@gmail.com> wrote:
I filed the following quick comment after viewing a six minute tutorial on variables and values at ShowMeDo.
The video:
http://showmedo.com/videotutorials/video?name=6950010&fromSeriesID=695
My comment: """ idea that values are "stored into" a variable is less the metaphor in Python, which is more about assigning or binding names to objects with the assignment operator (=). The problem with "store into" is then its hard to picture many names for the same object, yet that's easy when you think of a balloon with many strings. """
Yikes it posted three times dammit, makes me the foolish dweeb.
Someone took care of this, not sure why I'm anonymous as I used my name -- probably because not logged in? I added another comment supportive of his idea to make the model clear using garbage collection: http://showmedo.com/videotutorials/video?name=6950010&fromSeriesID=695
A better image is balloons on strings. I realize it's not customary to have one helium balloon with two or more strings, different hands holding each string, sharing the same balloon, but there's nothing conceptually difficult about it (feels kind of ubuntu), whereas with that dog in the doghouse... that way madness lies.
Someone pointed out off list that it *is* customary to have one helium balloon with two or more strings. In parades! http://images.google.com/images?hl=en&q=parade+balloons You might use these in the classroom, in slides, in tutorials. Each string-holder is a different variable name whereas the balloon itself is the object. So when do we get a Python balloon? Could be virtual I suppose. I think it's fine to talk about "Python's economy" i.e. there's an economy that is Python's, and includes memory management, the search path, other environment variables (if you've set them). Python then "paves the way" for these office buildings (many of them free) such as Zope and Twisted -- just download and go to town, plant them in your CBD (central business district) and put 'em to work (do some reading first -- takes time to become a FOSS boss (like the mayor of a virtual city, an economy)). Python is economical in not adding to the number of memory-hog objects gratuitously, simply as a result of assignment operations. For this reason, we avoid "dog in a doghouse" or "thing in a box" type metaphors when describing top-level naming. Even data structures such as lists are best approached with string (versus containment) metaphors. Given a primary notion of "string" already in popular consciousness is the URL (a handle), we can start thinking of objects as "servers" in the background, with variable names more like "clients" (with a channel open: client = server). Or instead of a web service, there's maybe a remote control engine on a track someplace, weighs a ton (literally) and several people have monitors with APIs for controlling it or at least displaying its location and status (moving?). When you go mystring = yourstring, you don't want the suggestion of cloning or copying something gigantic in memory -- you'd need to import from a different module for that, maybe do a deepcopy (more like a DVCS based approach). I use 'Code Guardian' (a short downloadable movie -- also on Youtube) to talk about controllable objects sometimes (these are big ones, giant robots by someone who knows movies really well) -- but mostly to talk about render time versus real time animation (this is render time). I run a course for Saturday Academy focused on animation concepts as this is ToonTown after all (we make lots of animations in Portland, especially when you count in the commercials e.g. Nike, Weiden+Kenney (http://www.wk.com/) http://www.cee-gee.net/Movies/Movies.htm (the source for the movie, others too) http://mybizmo.blogspot.com/2007/05/class-notes-session-three.html (suppose the robots aren't AI, but Python puppets)... Hey, big food fight on math-teach over whether to teach more SQL on a digital math track alternative to the continuous math track (analog) used by the calculus mountain people. I think I scored some points for DM. Litvins is helping by the way (its mere existence, snake cover not "too scary" -- reminds me of Prada). DM vs CM (DM winning): http://mathforum.org/kb/thread.jspa?threadID=1933378&tstart=0 Kirby 4D
participants (1)
-
kirby urner