[Edu-sig] Visual Programming in Python?
ianb at colorstudy.com
Thu Apr 20 05:26:26 CEST 2006
Jeff Sandys wrote:
> Kirby said:
>> So this isn't Logo, but it's probably where we're headed with
>> the turtle stuff:
>> t1 = Turtle()
>> 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
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,
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/shutil.py", line 81, in copy
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
More information about the Edu-sig