[Edu-sig] Visual Programming in Python?

[Ian Bicking]

kirby urner wrote:
>> 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 think "typing" is the wrong thing to look at.  A young child shouldn't
have to hunt and peck -- too many things to keep track of at once.  And
they shouldn't have to form grammatically correct code, which doesn't
mean anything to them when they are starting.

But that doesn't make typing as a whole bad.  So a typical entry into a
Logo environment involves a kid using the arrow keys to define a shape.
  They get some output, they don't have to hunt and peck, they have a
constrained environment.

None of which is necessarily *better* than a graphically composable
program.  But it's certainly a lot easier to create ;)  Where perhaps it
becomes more interesting is using these things as a path to full
grammar.  For instance, you hit some arrows, and you have a very very
crude paint program.  Not that fun.  But if you turn that into language,
then you have something more interesting.  E.g., they hit some keys,
they have a "shape", but the shape is actually represented as
programming text, like:

   [F F F R F F R F R R L L F ...]

That's the most simple representation, just the keys they hit.  You
could even use glyphs instead of letters.  But it introduces the idea,
and starts to open up areas for further abstraction.  In the geometric
world of turtles, it gives you a basic and nontrivial building block
(well, nontrivial depending on the age -- but you could also adjust this
accordingly).  It also lets the student learn from immitation -- in this
case, immitating the code created by the constrained interface.  Unlike
much-reviled code generators seen elsewhere, the constrained interfaces
would create human-editable code, and would not be a "complete"
environment (like no editing built into them).

Another kind of graphical environment that seems interesting to me is
representing lexical structure graphically (i.e., modules, classes,
functions, for/while loops, if statements).  I think this is a much more
conservative approach than drag-and-drop programming, but offers some
real advantages, particularly for some of the students who won't
naturally catch on to programming.  Rich literals is another similar
idea; e.g., given the right environment you could represent a color as a
literal, with the color inlined into the code and editable with a color
selector.

Both of these fit in fairly well to the Python programming model, just
not into the typical toolset (including Python's most basic tools, like
the loading of modules).  With the AST branch merged in Python 2.5,
maybe introducing different parsers would be more feasible than previously.

> 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).

Re: Logos, I haven't looked for a while, but last I looked just a couple
implementations stood out.  TurtleTracks in Java was one.  UCBLogo was
architected for the days of DOS, with very limited computer resources;
there's been some recent work to improve it, but I personally don't
think Logo is so hard to implement that it's worth starting from there.
  NetLogo and StarLogo are Logo, but also feel different than the
average Logo.  There's a Mono Logo that looks pretty good:
http://liogo.sourceforge.net/ and Elica is another nice Windows-only
Logo, that's not open source but is free, and I think at least deserves
some attention if you are thinking about approachable projects for a 3D
environment (like VPython).

An interesting exercise might be translating some parts of Computer
Science Logo Style (http://www.cs.berkeley.edu/~bh/logo.html) into
Python, to get a feel for how much of a text like that is related to the
language, and how much to the environment.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org