Logo (was: Re: My ideas may not be compatible with yours but...)

["Ian Bicking" <bickiia@earlham.edu>]

> And lastly, off the subject, is there anyone here that really knows their stuff with
> regards to Logo? If yes, let's talk logo and empowering teachers and students to create
> their own educational software....

I'm quite interested in Logo myself.

In the past I made a Logo to Scheme translator.  It was directed at 
Guile and the translation it advertised.  Since then I've become 
disallusioned with that goal, but that's another issue entirely.  
Nevertheless, the idea of translation into Scheme still interests me. 
To translate into Scheme entails a couple of changes to the 
dialect, some of which might not be a good idea, but I've yet to 
decide one way or the other.  What it can allow is a faster system 
that could be more self-hosting.

What I was thinking about was basing the translator in Guile, then 
writing (in Logo) the graphical primitives using guile-gtk.  As other 
things are interfaced with Guile, these components could be added 
to the Logo fairly easily -- be it a database, an animation program, 
or more generally a CORBA interface.  This seemed like a decent 
way of making a fairly powerful version of Logo.

However, I'm unhappy with my first translator.  There were a 
number of problems with the design, as much with the dialect of 
Logo as the implementation.  I've been thinking about rewriting this 
to be self-hosting -- using my old dialect of Logo to make a new 
translator which will then be able to translate itself.  This would 
also work to the goal of being a more transparent system, where 
more of the code is available to view and learn from.  This was 
influenced by my own learning from Squeak, which was much 
enhanced by its transparency when compared to most other 
programming systems.  Sometimes I think an adaptation of some 
of the things in Squeak towards children would be better than Logo, 
but Logo does have its history...

That was one thought.

Another direction to go would be UCBLogo.  It is, after all, GPLed 
and available on Linux.  I believe it was originally developed on Unix 
as well, but that probably doesn't make much of a difference.

MSWLogo (for Windows) is based on UCBLogo, and it does a 
number of interesting things.  It's a decent version of Logo, though 
it lacks a number of the bells and whistles that other versions of 
Logo seem to have.  It's interface doesn't much excite me either.  
However, it shows that UCBLogo can be a good basis.

I don't know how easy it would be to port MSWLogo to Linux -- 
probably fairly difficult.  However, it could give a model of how to 
upgrade UCBLogo to a more graphical environment.

The biggest problem I see in UCBLogo, as a language, is the lack 
of good data encapsulation.  As a result of this MSWLogo uses 
lots of different namespaces for various different datastructures, like 
graphical objects.  That is to say, things are referenced by names 
instead of as variables and objects.  Since I've never tried making 
windows, buttons, etc., in other Logos I'm not sure if they are any 
better.  But I know Logo *could* be better at this.

If people were to build real programs that had some polish to them, 
I think Logo needs to be rethought a bit.  And it would be nice if 
people could write these programs, because even if students and 
teachers would seldom write these programs, having such 
programs around to play with and learn from would be neat.


Another thing I'd like to see in a Logo for Linux, is a Logo in which 
you can create something like HyperStudio, instead of a 
HyperStudio with its embedded HyperLogo.  I don't know if 
UCBLogo is powerful enough for this.

I think there's a number of people who successfully use 
MicroWorlds this way -- as a multimedia tool.


So those are a few of the thoughts I've had.


--
Ian Bicking <bickiia@earlham.edu>