[Edu-sig] Visual Programming in Python?

[Ian Bicking]

Jeff Sandys wrote:
> Kirby said:
>> So this isn't Logo, but it's probably where we're headed with 
>> the turtle stuff:
>>
>> t1 = Turtle()
>> t1.forward(10)
>>
>> I can imagine a big commercial company contributing a colorful
>> professional grade edition to the education community, via GNU 
>> or whatever.  Making the syntax consistently Pythonic would be 
>> an attractive feature (implement bindings for both Python *and*
>> traditional Logo why not?).
> 
> Thank you, Kirby, for expressing this.  While PyLogo is an 
> interesting and valuable experiment, I don't think that it will 
> contribute to introductory Python programming education.  I love 
> Logo syntax and enjoy teaching Logo to Middle school students.
> I wouldn't use PyLogo when teaching Python.

PyLogo wouldn't be particularly useful teaching Python, since it isn't 
Python.  But it makes it possible to share infrastructure and 
environment between the two languages.  So (barring some small details) 
you could run VPython from Logo, and the students would be building 
familiarity with that model.  And I think there's no reason VPython in 
Logo would look much different than in Python -- the core concepts there 
aren't bound to the language, they are bound to the domain of 3D modeling.

A bunch of other parts are also relatively unassociated with the 
language, like the basic development process (editing code, running 
programs, etc).

As to the merits of Logo as a language and Python as a language, I'm not 
sure.  Logo is grammatically simpler.  Generally it is more insulated 
from the underlying implementation.  It isn't burdened with ideas like 
"good software engineering".  But it's not necessarily designed to lead 
to Python, as say Guido van Robot is.  But anyway, that's a different 
(though still interesting) discussion.  At least PyLogo lets you hedge 
your language bets a bit, if you are working on non-language concerns.

> What I would like to see in a turtle environment comes from 
> StarLogo ( http://education.mit.edu/starlogo/ ).  StarLogo has 
> multiple turtles, the turtles can inherit methods to make new 
> turtle classes, and the background also has methods for its cells, 
> implementing Conway's Life only takes several lines.  The Santa 
> Fe Institute uses StarLogo to teach non-programmers sophisticated 
> behavior and business simulations.
> 
> I think that creating a StarPython, with Python syntax, would be 
> a more valuable effort that forcing Python to resemble Logo.

That's hard, or maybe easy.

With CPython, something like StarPython is hard. The kind of concurrency 
it does isn't practical with OS threads.  Maybe with Greenlets, though I 
must admit I don't understand them.

But with Stackless Python it might not be so hard, at least within 
certain constraints.  Cooperative microthreads are possible there, and 
that's kind of at the core of StarLogo's system.  Implementing the 
turtles from that point might not be so hard.

That said, I'm not sure how well Stackless interacts with C extensions, 
i.e., the graphics available in Python.  I guess that would be something 
to try out.

> Python would be easier to teach if it had clearer error messages. 
> Most Logo error messages lead the programmer to the solution for 
> the bug.  I would like to see an IDE that had Doctest and maybe 
> profile as a button in the menu bar.

Error messages are indeed hard.  It's easier when you have a clear idea 
of system and user code.  In a typical Logo implementation where the 
library is implemented in a language other than Logo, it's easy to tell 
what is inside and outside -- everything in Logo belongs to the 
programmer, everything not in Logo belongs to the system.  In Python it 
is not so easy, especially because errors often bubble up from deep in 
system code, and you actually have to inspect the system code to 
understand what it means in the context of your code.  As an example, 
shutil(None, 'tmp'):

Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/lib/python2.4/shutil.py", line 81, in copy
     copyfile(src, dst)
   File "/usr/lib/python2.4/shutil.py", line 41, in copyfile
     if _samefile(src, dst):
   File "/usr/lib/python2.4/shutil.py", line 31, in _samefile
     return os.path.samefile(src, dst)
   File "/usr/lib/python2.4/posixpath.py", line 218, in samefile
     s1 = os.stat(f1)
TypeError: coercing to Unicode: need string or buffer, NoneType found

Sigh.  It's not like hiding that traceback can make that error more 
understandable.  I really don't know how to resolve that.

Though it definitely is possible to trim exceptions down.  For instance, 
not to show code that is part of the standard library (or at least 
filter that out unless explicitly expanded).  That won't make the 
exception make sense (coerce to Unicode?! talk about obscure), but at 
least it will better highlight the problem code.

> Another advanced Logo is Elica ( http://www.elica.net/ ).  Elica 
> has 3D geometry, a nice object browser and abandons the Logo like 
> Ask and Tell object syntax for Python like dot notation.  Elica 
> architecture allows linking other programs.  I imagine a close 
> integration of Python and Elica ( Pelican ? ) but this is beyond 
> my programming abilities.

Elica is definitely interesting.  It seems pretty bound to Windows; or 
at least the graphical side, I would assume.  A Windows dependency seems 
like a problem for many of the target projects.


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