[Edu-sig] Visual Programming in Python?

[Andrew Harrington]

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.

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.

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

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 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.
>_______________________________________________
>Edu-sig mailing list
>Edu-sig at python.org
>http://mail.python.org/mailman/listinfo/edu-sig
>  
>


-- 
  Andrew N. Harrington
  Computer Science Department      Undergraduate Program Director
  Loyola University Chicago        http://www.cs.luc.edu/~anh
  512B Lewis Towers (office)       Office Phone: 312-915-7982
  Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
  820 North Michigan Avenue        aharrin at luc.edu
  Chicago, Illinois 60611