[Edu-sig] core versus superficial Python

[kirby urner]

I've been offering some pointers to this gentleman
in Indonesia wishing to learn Python.

What's clear to me is he's chomping at the bit to
get to the most impressive use case demonstrations,
involving  VPython, matplotlib, other 3rd party packages.

He's not giving himself much time to just mess
around in what we often call "core Python" (prevalent
nomenclature, not my invention).

This means he's deeply into issues such as
re-scaling x-y axes for a plot, before ever writing his
own class definition.  All those tiny little examples
involving Foo and Bar, giving simple step by step
explanations, get skipped, in the rush to graph
something sexy.

I'm thinking a benefit of a curriculum such as Litvins'
is you're allowed to stay within the core and not have
to master many if any add-ons.  That's kind of a cool
luxury, to get a lot of face time with pure Python, before
needing to encounter Sage, matplotlib, numpy or one
of those.

One might use other tools entirely for plots sometimes,
say Java applets with easy GUI tools.  It's a hybrid
environment, with many technologies on display, a
kind of a smorgasbord.  Yes, Python is on the menu,
but so is a lot of stuff, varies by teacher.

My Saturday Academy courses have been slightly off
this core Python path in that I use VPython from the
start, because of it's high bang for the buck value.

Being able to get some spatial geometry going pretty
quickly is a strong enticement, a big win for low
overhead.

But I provide a lot of initial scaffolding and really
spend a lot of time just sticking with core basics,
using visual only sparingly in some meetups.

Having visual output is one thing, but purely visual input
is something else again.

[ After a certain age or stage of readiness, I'd rather
see learning a coding language as more of a
left brain exercise, a lexical activity.  Always dragging
and dropping icons, working visually, provides lots
of work for developers of such environments, yet
always feeding those expectations, of "everything
graphical" is too often a set up for future disappointment.

Coding a video game, and playing one, are two different
kinds of activity, we should not lie about this difference by
always promising too much eye candy.

Core Python includes importing from standard library, is
not about denying ourselves access to sys, os, math
and many more... including turtle.

Programs like Sage on the other hand, take minor liberties
with the syntax itself.  That's "minor" in one sense, but
in another sense you've removed a some boundaries,
somewhat fuzzed the picture as to what Python is.

If you have the luxury of being able to stay with core for
awhile, that might be to your lasting benefit.

A pre-college math course that's somewhat low pressure
when it comes to whatever scripting language, not pushing
too far or too fast, staying safely in a sandbox a lot of the
time (not adventuring with add-ons too much), is going to
be helping a diverse population.

Why?  Because a primary objective of this go-slow
approach is to explicate broadly applicable mathematical
concepts, not narrow concerns about syntax.

Because the programming language is only part of the
mix, not the only focus, some days the lessons have
nothing at all to do with coding.  Whole days go by when
no whatsoever code is entered or evaluated.

We might be making polyhedra with scissors and glue
(or in my case, with snap-together identical parts,
translucent plastic, no glue required):

http://www.flickr.com/photos/17157315@N00/4328444871/

A great example of what a computer language might help
demystify is Sigma notation.  Math texts are full of capital
greek Sigma symbols.  However these may come across
as highly mysterious on first pass -- the beginning of
the end for some students, when they start to glaze over.

With the semantics of do-loops (while loops, for loops)
side-by-side, one explicating the other, the topic has
not become doubly difficult.  It's now only half as hard.
Two views are better than one.

This has been my finding at least, and the implications
are far-reaching.  Nor am I in any way alone in making
this discovery i.e. this train left the station, had gathered
steam, before I hopped aboard (I was recruited through
APL, is how I tell the story today -- wouldn't have stuck
around if it was all Fortran on punch cards... all because
of REPL, still important  i.e. the fun of immediate feedback,
no need to compile and write lots of prompts for inputs
to compensate).

I'm going with Computational Thinking as a course
name for trial balloon purposes.  So far it seems to
be gathering altitude.  There's always the course
description for getting wordy.  That's where you might
say something about discrete math, or a mix of
traditional and more contemporary topics.  Some
curricula will dive into cellular automata, some into
polyhedra, some into both, some into neither...

My thanks to those who suggested Computational
Thinking as a possible moniker.

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20100203/dbdf0176/attachment.htm>