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 | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
