[Edu-sig] Visual Programming in Python?

[kirby urner]

> Very good point.  The way I see it would be that this would be a
> tool to teach beginners about control statements and program
> flow *for relatively simple programs*. Something like a "guess
> the number" or your the word substitution program (mad lib?)
> that you talked about previously.  The idea is to have something
> complementary to other tools (like turtle graphics, etc.).
> At least, that's _my_ take on it :-)
>
> André

Yes, that's a reasonable interpretation.  But from my point of view
it'd be overkill.  A few diagrams of the traditional flowchart type
should get the point across, then move into nongraphical coding.

But this brings up an interesting point:  should we try to assemble
Pythonic tools that go into graphical hand-holding down to such a
level, e.g. for very young children?

Alan Kay strongly believes a young child shouldn't have to type to
experience programming, i.e. some kind of drag and drop or other
non-typing interface should facilitate programming.

I have no problem with that if (a) we accept that typing will become
important later and (b) don't insist that core Python has any
responsibility to pander to non-typers.

I do agree with Arthur that Python shouldn't pander.  It was
originally designed as a kind of teaching language, user friendly for
newbies, but not newbie children, rather newbie adults with a
professional need to program for some reason (e.g. telescopy experts,
biologists, chemists or whathaveyou).  That's the heritage and I don't
see any reason to pretend otherwise.  Python was never premised on
being "kid friendly" in the way Squeak was.

So if other environments e.g. Squeak or Lego Mindstorms, already have
ways to accomplish this "almost no typing goal" is there any reason to
commit the resources of the Python community in this direction?  In
other words, is there any reason to try pushing "snake language" into
this ecological niche, and in what sense would it even be ostensibly
Python any more, if we did?  If it's just the implementation language,
then it'd be somewhat hidden -- so then why not use something faster?

I keep coming back to the notion that heterogeny is a good thing.

One exercise we did at this Shuttleworth Summit was stand on a line
according to how much we agreed with the statement:  if we *could*
implement a 10 year long curriculum around one language only, we
should, at least for testing purposes, i.e. to see how well it worked.

I stood fairly far at the other end as I recall (disagreeing with the
statement):  it's a curriculum *goal* to not get mired in one and only
one language.  We *want* diversity and making Python do the whole
thing would be a bad idea in principle.

But that's NOT to say we shouldn't have turtles, robots or other
kid-friendly stuff in Python.  It's more to say that it's being
implemented in Python is not the chief advantageous feature (as if we
expect kids that age to dig into the source code).  The pedagogical
advantages should be around the quality of the lessons and
experiences, regardless of the implementation language, no?

That being said, if one turtle or robot environment is free and open
source, while another is closed source, proprietary, and possibly
expensive, that *is* a feature to advertise as advantageous.  However,
Pythonic products needn't be free or open source, we already know. 
Pythonic is not synonymous with FOSS, even if the language itself is
FOSS.

Just thinking out loud here.  One of our Shuttleworth Summit attenders
was going back to Cape Town with Imagine Logo, a somewhat expensive
commercial Logo aimed at the kid market (I guess that's redundant: 
Logo is by definition aimed at kids, no?).

If we're to support the tentative Shuttleworth approach of using Logo
with the youngest kids (then Squeak, then Python), we'd need something
free and open source, and probably cross platform.  There's no budget
for expensive software in this picture.

We need to start assembling candidate packages that'd run in a Tux Lab
on Edubuntu I guess.  What Logos?  Squeak already works.  Do we need
to include wx in that distro?  Is it included already?  How about
VPython (required for Pygeo, among other packages).

I'll have to poke around more when I get back to Portland, where Derek
has it installed in his test bed.

Kirby
in London

PS:  hope OK I'm replying to the list; your previous came to me only
but doesn't appear confidential in any way.