Re: Logo

[Malonowa <malonowa@wanadoo.fr>]

Ian Bicking wrote:

> [translation stuff...]
> > This sounds very interesting but I don't know anything about Scheme or
> > guilt-gtk.
>
> Scheme is a dialect of Lisp.  It's fairly minimalistic.  Basically, it is
> a simple and reasonably fast language (as interpretted languages
> go) that has some similarities to Logo, since Logo is a dialect of
> Lisp as well.



> Guile is the GNU implementation of Scheme, directed toward being
> an extension language, <http://www.gnu.org/software/guile>.  One
> benefit it has is that It can translate Scheme (and, one would
> imagine, translated Logo) into C for some speedup (even though it's
> not as fast as normal C code).  This could make it possible to write
> more significant portions of code in Logo, translating speed-critical
> parts to C.  I haven't tried this, though, so I'm not sure how well it
> works.
>

> [I've also considered that MzScheme/DrScheme might be a better
> target...]
>
> Scheme and Logo aren't a perfect match, but I think there's some
> advantages in having Scheme-like semantics and a Logo-like
> syntax (which is more or less what a translator would do).  To do
> the translation I gave Logo lexical scoping instead of the traditional
> dynamic scoping, which was the biggest change.  Most of the time
> you wouldn't realize the difference, but it comes up.  The now
> defunct Object Logo did this, I believe.  But I never found much
> information on Object Logo, so I don't know quite how they went
> about it.
>

I'd be grateful if you'd explain the terminology here at idiot level - I did a course writing a
basic Oberon compiler a long time ago. My memory needs refreshing.I didn't know that there was an
Object Logo.

> The other significant change I made was that variables were really
> variables, so that :VAR isn't equivalent to THING "VAR.  And some
> other things here and there...
>

variables in logo would definitely need a lot of work. If we were to implement multiple turtles
then we'd have to implement dynamic structures and pointers so I think the way the language deals
with data would have to be added to considerably.

> guile-gtk is just the GTK bindings for Guile.  They provide a fairly
> Scheme-like interface to GTK, which is a close match to what a
> Logo-like interface would probably look like.  This would
> significantly cut down the work required to put graphics into the
> language.
>

I'll have to go and read about guile and scheme so I can appreciate what you're saying. Where this
subject's concerned you're much cleverer than I at this stage.

> > I was thinking of an object logo similar to Starlogo by MIT. Then you could have turtle
> > inheritance and so on. It would be a great way to teach object orientation as well since it
> > would break down a lot of the terminology into a more naturally understandable form.
>
> I've only used Starlogo a little bit.  Admittedly, it was too unfamiliar
> and I didn't put enough effort into really figuring out how it all
> worked.  I should probably try using it some more.  The multi-turtle
> thing seemed to be its raison d'etre, so I didn't notice if there was
> an object-oriented underlayer.
>

The multi-turtles are objects essentially, they can inherhit from eachother - I believe. I think
the multi-turtle idea's interesting but I wouldn't model a new logo on Starlogo - I think the
extensions are there for a very specific reason - decentralized systems.

> > Couldn't
> > we write an embeddable interpreter? A logo interpreter modelled around the way TCL works
> > could be interesting. Imagine CGI scripts in logo!
>
> That's one of the things that translating to Guile would allow, more
> or less.  Guile attempts to replace Tcl in terms of functionality.  But
> I'm not actually sure how much use it would be.
>
> But CGI scripts are already mostly possible with UCBLogo.  All a
> CGI has to be able to do is take information from stdin and put it
> out to stdout.  Making it work nice, and making it accessible to
> children is another issue.  But that could probably solved within
> Logo.

Creating dynamic graphics is another issue here which Logo is well suited to.

>
>
> I know somewhere there is a version of Logo which you can embed
> in web pages... maybe it's that Java Logo (Turtle Tracks)... but I
> feel like it was something else.
>
> > > 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.
> >
> > I think taking the interpretation code from this program and adding to it would be a good
> > idea. Putting a nicer interface on it to make it more accessible to younger ones would be a
> > good short term goal and would familiarise with the code.
> >
> > If you were interested I could draw up some designs for that.
>
> That could be a good direction.  It would certainly result in the
> fastest results.  I haven't looked at the UCBLogo sources before,
> so I don't know how easy it would be to work with.  If you want to
> look at that and report back, that would be great.
>

Will do.

> > I don't think MSWLogo approaches the GUI stuff very well. I think hatching turtles and turtle
> > patches would be better.
>
> What are turtle patches?  I haven't heard that term before.  And
> when you say it doesn't do GUI stuff well, do you mean generating
> GUIs from Logo programs, or the GUI that MSWLogo itself uses?
>

Turtle patches are groups of turtles. So you can perform actions on families of objects. In
starlogo the patches are defined by colour I think.

Example: Taken from Starlogo site.
                     if xcor > 12 [sprout [setcolor blue]]
                     (Each patch to the right of xcor = 12 creates a new turtle that sets its
                     color to blue.)

I think patches in Starlogo are aware of each other as well.

I can see the use for artificial life simulations here but in applications programming ? What do
you make of patches?

I like the idea of being able to group a whole series of objects together and manipulating a group
though.

> > I think logo is potentially a very impressive and powerful language with some more modern
> > extensions to it and it's pretty easy to understand. I would really love to have a good
> > development environment based around this for real applications. I think that there could be
> > many teachers who may have a basic knowledge of the language who may get into a bit of
> > programming - and students as well. We mustn't overlook what students can do to educate
> > eachother. Anyway, why should languages like TCL and PERL have all the fame when Turtles are
> > much more charismatic!
>
> Yes, I do think Logo has a lot of potential.  Lisp without the
> parenthesis :-)  If you look at Tcl, it's almost exactly like Logo
> except with strings instead of lists... but that's incidental.
>
> But it is a niche language.  The realm of education is an important
> one, but sometimes I wonder if it's bad to make distinctions such
> that you get software only useful in an educational context.  KidPix
> is cute, but the Gimp is so much better... I'd hate to just make a
> KidLanguage.  Just a concern.
>

I might say here that how niche is a language which doesn't exist yet but people create them -
Python, Perl, Eiffel.....

This is a very interesting point. I've administered a company using educational software! It's how
you apply it I think. But educational software doesn't have to lack power.

Gimp could be kidpix. All you'd have to do was add a few more configuration options for different
levels of ability.

Logo could be a very powerful language. My idea is that you would introduce more and more of it at
different levels of ability and if students don't know that something exists it's not going to
baffle them - and if they do find out and work it out then all the better.

For example, you could use UCBlogo with 5-7 year olds but all they'd use would be a small subset of
the language:

fd n, rt , (repeat maybe at 6-7) etc.

With a nicer interface. So they could click on icons which perform the actions and wouldn't need to
be too aware of the syntax. Then the language is used more as a tool to help with estimation,
spacial awareness and basic control technology. The fact that they can input data and get a visual
response from it.

You could for instance, have problem files that could be loaded which put up simple maps and change
the shape of the turtle. So they could use logo commands to guide a dog to a bone on the screen.
This is not the language, it's an interface sitting ontop of the language that's using logo to
visualise the child's input. You could write the interface in logo!

Then from 7-10 years you would introduce the syntax of the language, loops, simple data,
procedures. Then they'd be getting into more advanced control technology. The idea that they can
input data and get a response but that they can modify this data, and analyse the results. That
they can test their sequences, optimizing where necessary.

From 11-16 you'd be gradually introducing heavier programming concepts with the language.

And after that the language becomes a full development environment.

So you're always using the same language but presenting it differently.

I think that what I'm try to say here is that in an educational context it's not the Logo language
that's the issue it's the user interface that changes and the problems we expect the student to
solve.

> > > 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.
> >
> > Is hyperstudio like hypercard? Never seen it? Could you elaborate on this so I can
> > understand?
>
> I think HyperStudio does come from HyperCard.  It's basically a
> multimedia presentation program, with a scripting language based
> on Logo.  The version of Logo they use is pretty wimpy, though
> they deserve some credit for using Logo at all.
>

I thought of this a few days ago. If only I could've done these things a few years earlier!

Turtles would be good for creating interfaces. I can easily visualize a turtle wandering around a
window hatching little button and entry box turtles. It's like packing widgets but without the
heavy terminology.

So you could have interface turtles, media turtles, printing turtles etc. Then you just have to
hatch them and tell them what to do.
You could knock out a multimedia presentation like this pretty quickly and add some conditonal flow
where necessary. Or indeed create a program that creates a multimedia presentation.

So if it was all done well you could have a powerful language that was very easily accessible to
new programmers.


> Anyway, it's very popular here in the US, from what I understand.
> In the school district I work it's the only educational program that is
> consistently used by all the students.
>
> With a version of Logo that integrated well with other apps and
> libraries (like imlib, xanim, Mozilla, and so on) you could perhaps
> make something that allowed the integration of these media with
> Logo being more than an extension language, but actually at the
> core of the system.

:-)

You'll have to forgive me if I'm loose on the technical issues here I will read further on
everything.