[Edu-sig] Visual Programming in Python?

[kirby urner]

On 4/16/06, Andrew Harrington <aharrin at luc.edu> wrote:
> Several points on visual programming and flow charts ...
>
> 1.  Visual programming in Python is complicated by the fact that it is
> not statically typed.  If you want x to be assigned the reference
> returned by function f, you cannot be sure of the type, so it is hard to
> then be able to have a GUI element to select a method to use with x.

This shouldn't be a huge problem.  Visual FoxPro isn't statically
typed either (reassign at will, no need to pre-declare type).  Dynamic
typing is in no way inconsistent with visual GUI programming, round
trip or otherwise.

> 2.  On loops and flow charts.  I am clearly behind OOP at all sorts of
> levels.  My judgment is that OOP texts tend to ignore the fact that
> inside methods there are algorithms with good old loops and decisions,
> and students have a hard time with them (particularly loops) and they
> need to be taught effectively.  They are underneath objects, and they
> are definitely there and important.  A flow-chart-ish approach to
> visualizing them might help.  I'm not sure.  I have tried lots of ways,
> but not used flow charts much.

You're right, shouldn't ignore that Python methods are procedural
code, makes sense to do mini-function coding first, then explore OO
coding (except one might visit dot-notation even prior to
mini-function coding -- what's worked for me in the 8th grade
context).  Looping and branching -- can't get around those.  Not
irrelevant in any way, just because of later OO developments.

> Obviously if you are trying to set up a model of a complicated domain,
> you are likely to have all sorts of objects, and the interfaces between
> the objects are key, and you can use UML, or all sorts of schemes.  I
> would not use loop modeling tools to model an object-oriented domain at
> the top level.  Still, if you are going below the level of overall
> design to actually programming through a graphical interface, you get to
> down to loops and decisions, and a graphical flow through them could
> definitely be useful *within* a method.
>
> Andy

I like the idea of diagrammatic representations of problem domains
using some kind of boxes and arrows notation, something not too formal
and doesn't have to generate code.  The imagination glues the diagram
to the code -- not a step we should have to automate before continuing
with serious-minded CS-type training in a developing world context.

I'm very open to more GUI tools coming on-line, but don't see any
particular absence as halting progress until we have same.  In other
words, we already have enough tools to get on with it.  I'm not
waiting for large new green field development to occur, even if I
expect such development to keep occuring anyway.

That's good, because bottlenecks are just we don't need any more of at
this point.  The TIMMS scores tell the story.  The situation is
critical and needs more than just another long-delay type response.

We're not "on hold" waiting for any geniuses to get back to us.

Kirby