[Edu-sig] teaching Python

[Kirby Urner]

Arthur:
> But to what extent are you fulfilling your mission to teach programming by
> using Gamemaker? Its  a question, not a provocation, since I don't know
> the program.
> 
> Do you ever get to something that can be considered, fairly, to be
> programming?

FYI, Gamemaker does expose a coding layer that requires some Java-like
programming.  It also does a lot out of the box at the click and drag level
-- then you can see what you've wrought in terms of code (the palette-driven
GUI design motif, applied to dynamic interfaces).

At Saturday Academy, Gamemaker is a well established offering and the word
of mouth on it is positive, i.e. kids learn from other kids that this is a
fun course or courses (I think we might have a beginner and advanced level
-- you'd have to check the catalog).  

It serves as a motivator towards programming, in that eventually you become
frustrated with the limitations of the point and click constructions, and
the teacher says "OK, you'll need to start learning this OO language then."
Some kids drop out right there -- others stick with it.

A possible drawback of Gamemaker (I should be corrected if I'm wrong) is
that the OO language you need to learn isn't specifically any of the
mainstream languages -- it's Gamemaker language, which is Java-like but not
Java.  Did I get that right?  The Satacad instructor (Edwin Pilobello) gave
me a quick tour of the package awhile back and this is all I'm going on.

Even if that's right, this isn't a super-serious draw back.  You get your
feet wet in a Java-like language.  How bad can that be?
 
My approach to teaching Python is to mix it with a different knowledge
domain, but not GUI game making (not that I have any problem with PyGame,
but that's not so friendly to newbies as GameMaker).

I lean towards using mathematics as my place to cut new programming teeth.
At first glance, that sounds like a real turn off.  Doesn't it just take the
fun out of programming to tie it to a boulder like math, and throw it off a
bridge.  We just sink to the bottom, right?  But look at it this way:  they
want you to learn quite a bit of math *anyway* (the boulder is a given) and
approaching the stuff while learning Python makes the math more fun.  In
other words *given* math is important, Python has way more to offer in the
fun department than just graphing calculators.

I think of PyGeo is fitting somewhere in between these two extremes.  My
math stuff tends to be pretty stark, pretty austere, although I too phase
towards visuals with POV-Ray and VPython.  PyGeo gives students an
interactive command line for creating dynamic interfaces (like GameMaker
does), but with stronger ties to mathematics (projective geometry and such).
Then at the other extreme you have GameMaker, where you've cut loose from
formal math and have to think of some rules that might actually make for a
fun experience, i.e. the challenge is to come up with something worth
playing (an art in itself).

Another approach in which I've been successful with Python is mixing it in
as one tool among many in a kind of open source work shop.  We're in this
bicycle shop (metaphor for Unix-like work bench) and want to know how to fix
and assemble bicycles.  Python lets you script stuff -- an alternative to
bash scripting (Perl got off the ground here too).  Python lets you throw
together some cgi (e.g. the calendar example).  

In both applications (scripting and cgi), working in Python helps you learn
this new knowledge domain (just like it helped you learn math).  You become
acclimated to a whole range of new concepts.  Note that we're not doing 100%
Python programming here.  We're getting used to a context, a set of tools.
Synergy is key -- always has been in Unix-like worlds (many special purpose
tools with orthogonal relationships, like Python itself, sort of).

Kirby