[Edu-sig] Webster Van Robot

[kirby urner]

On Mon, Sep 8, 2008 at 7:07 PM, Steve Howell <showell30 at yahoo.com> 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