On Mon, Sep 8, 2008 at 7:07 PM, Steve Howell <[EMAIL PROTECTED]> wrote:
... > Most of us learn to read before we write, so I'm not so sure it's necessarily > a bad thing to introduce OO to students as consumers before they become > producers. On the other hand, I totally understand your desire to have > students write their own objects from the beginning. > Yes agreed, big difference between "recall" and "recognition" when learning a language, including a human one like Spanish or English, and it's important to eyeball mature code long before it's important to write such code to a blank canvas, a much more daunting proposition. So yes, I believe in "scaffolding", by which I mean canned or pre-written code, designed to get students comfortable with the look and feel of this language, which may seem quite alien (worse than Klingon) to start with. But it's still easier than J, I would contend (another language we might look at, as I believe in at least glancing at mind-expanding examples from outside whatever core language, if we agree that there is one -- could be projected content, nothing installed on each student computer). > What's an example of a small Python program that your students have written > that uses objects that they built? Do they start with model/view/controller > objects or otherwise? > I've experimented with different techniques but one of my current favorites is to define a Snake class with a stomach, a method for birth (__init__), eating, and maybe elimination in a second (more complicated) example. __repr__ also defined and explained. You may not be aware of my tendency to call special names __ribs__ inside an "everything is a Snake in Python" by which I mean some kind of object, like an animal (special names look like ribs). Per many posts to this list, I take a zoomorphic approach to OO, as I'm assuming your average student likes thinking in terms of animals. Another rhetorical ploy is to make the first class definition Biotum, again with an eat method, the idea being that primitive objects like lists and dictionaries are more like "proteins" (building blocks), whereas the Biotum marks the first time we need a "self" concept (something to anchor "this instance" versus "that instance"). Functions are in between, more like organs or organelles, turning into methods when absorbed into this higher life form. I'll go through all this quickly on the first day (presuming a class), then go over it again much more slowly, spending a lot of time with functions especially. I'm somewhat inclined to do generators early as well, as I find them a small step from functions, just replace return with yield and make it a loop of some kind. When working with math teachers, it's all about functions as well, including figurate and polyhedral number sequences per AT&T's On-Line Encyclopedia of Integer Sequences, e.g. a first function might be def cubocta( f ): return 10 * f * f + 2, which has to do with one of the more important lattices in the sciences: http://www.research.att.com/~njas/sequences/A005901 (you'll find my name in the links section). > >> As I mention in my Chicago talk, I tell my students >> "I've never heard >> of procedural programming, it gives me the creeps" but >> that's just a >> rhetorical device to get the ball rolling, as I start with >> dot >> notation immediately, within the first 10 minutes. > > Do students ever get confused by the dot notation, or at least frustrated > with the wordiness? I'm sure that they do, but a higher priority is to decipher the mysteries of this weird grammar, with all these __ribs__ and dots and whatever. One of our first exercises is to go dir( 1 ), just to show that even primitive numbers "know a lot" i.e. have internalized structure as objects (are like snakes in that sense). My pitch to the math teachers is it's time to recognize "dot notation" as part of our basic math notation, now that these several languages have implemented it somewhat consistently (Javascript included). This prejudice against executable notations being "not mathematical" is what I'd call a prejudice, or superstition. > >> But >> that's because >> I'm teaching core Python, not another language >> *implemented* in core >> Python. These aren't little children. >> > > I think it's great that you have students who are ready to jump right into > core Python, but I don't think you have to be a little child to benefit from > small languages like Karel, Logo, and various cousins. When I was in > college, lots of non-CS students got exposed to programming through Karel and > got a lot out of it. That was nearly 20 years ago, so I'm sure today's > generation comes in with a little more sophistication, but I still see the > benefit of starting with a language with very limited syntax. > Yes, agreed. Also since the last OSCON I've developed new respect for Scratch from MIT. http://scratch.mit.edu/ Nat Torkington was talking this up during his keynote (different from the Nat I said hi to recently re phidgets (above)). > Even if you have a bit of programming background coming into a small > language, it can still be a really refreshing exercise to work within its > limitations. One of the funnest programs I ever wrote was to have Karel > determine whether his beeper world was palindromic. Try to do that without > variables! > Yes, no reason we have to start with Python, or even if we do, no reason we can't move to these others in addition. > Getting back to little children, though, I do think there will come a day > where smaller children learn to program as easily as they learn reading, > writing, arithmetic, music, etc. > Maybe. I'm thinking it's more like piano, where some will feel drawn, some will be prodigies, others will have burdensome geek parents who insist that Sally or Johnny start writing Perl at age 6, come hell or high water. I can't prevent these abuses, just go on record with my view that there's no huge rush to get into it, take your time -- but if you love it, you love it. Kirby _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
