Re: Logo

[Malonowa <malonowa@wanadoo.fr>]

bickiia@earlham.edu wrote:

> GTK would be my personal preference.  In particular, the Canvas sounds
> like it will make turtle graphics easy to mix with widgets, as well as
> leaving the potential for some of the more multimedia aspects as in a
> program like MicroWorlds.

Just a pixmap for double buffering would probably be best. Then we can use
imlib to handle lots of graphics formats and special effects. I'm thinking
about writing little games and the like here. I'll have to read exactly what
the GTK canvas will do.

Then that creates a problem. What do you do when you want multiple windows
and canvases? I'm assuming that we'd need multiple turtles here. The best
thing is probably to modify berkley logo so that it can deal with all of
these things and run serious programs then write the kids interface using
the logo itself.

The interpreter needs to be extensible in a similar way to Wish from TCL/TK.

> I think it might work for teachers who already know Logo, but I don't
> know if it will appeal to many other people.  I just see too many
> languages that attempt to be this, and few of them succede.
>
> OTOH, many a language is infected by a desire to look like C, which is
> of no good to anyone but people who know C.
>

I think if someone's never programmed before then Logo would be a good start
- especially if it was powerful enough to give them something decent to show
for it. I'm keen on coming up with something a bit like Delphi but
interpreted Logo. I've also said before that the maybe a pseudo oop Turtle
concept would be much easier to understand than c++ or object pascal etc.
When I first started to program many moons ago it was BASIC on 8 bit
machines. Then I came across a logo interpreter called Honeylogo. I wrote an
adventure game in it. Why? Just for kicks... There's something very charming
about logo and it's turtle(s) - don't quite know what the appeal is but I'm
certainly not alone in feeling that way.

> I see helping new programmers and programmers who are experienced on
> other systems as very different things.  For people who know other
> systems, moving to Linux is a matter of explaining the system in
> relation to what they already know.  But someone without much experience
> doesn't need comparisons.
>
> True.  There is a lot of room for tutorials.  The other aspect is just
> getting everything to work together -- the raw details of compiling,
> starting interpreters, using editors, and all that.  Even Hello World
> can be fairly difficult at times.  GTK/Gnome have some cute little
> programs that set up the command line for you... maybe more stuff in
> that direction would be good.
>
> I'd hate to introduce programming-by-wizards into Linux, though :-/
>

I've got no idea how to use autoconf etc. The info on all this is all over
the net and I haven't had time to track it all down yet. I think tutorials
are in order but well written tutorials. If there are any computing
lecturers out there who are used to writing course material then they could
probably come up with something that makes more sense than the stuff out
there right now.

A lot of the tutorials are ok but they miss the little details that are
important to people who don't really know as much as the authors. I find
myself reading these things, understanding most of it and then having to
spend a lot of time trying to work out simple little things that should've
been in the tutorial to start with. Anyone used to teaching programming
would probably not miss out on these little details. At the end of the day I
think it's about assuming nothing of the reader.

> >Maybe if there was something a little more dynamic it could be embedded
>
> >in a web page as a Java applet. Then there'd be fewer restrictions to
>
> >the content. That seems to be the way things are going now anyway with
>
> >pdf, flash etc. having readers in Java.
>
> Even Javascript can do quite a bit.  Being able to put canned Javascript
> into a page would extend things quite a bit.  Something in the way of
> CGI is another possibility, though more complicated.  Perhaps Zope (or
> something like it) could be used for some canned CGI abilities...?
>

Once you touch CGI then anyone who wants to look at the work needs an http
server. So you couldn't just take the work home and look at it from your
hard disk or whatever.


Back to logo,  can we make some firm decisions now as to how we'd deal with
widgets and windows in logo? Then we could get something going. Personally,
I like the idea of multiple turtles a bit like objects. What do you think of
this.

I like the idea of having different types of turtles such as a window
turtle, graphics turtle, sound turtle etc. Then being able to create them
with names like "Billy" or whatever. So if "Billy" was a window turtle you
could TELL BILLY TO CLOSE or whatever syntax we'd use. Or if billy was a
graphics turtle, tell billy to fd 100. Or set billy as the default graphics
turtle and just fd 100.Get the idea? So billy inherits all his properties
and methods from window or graphics turtle. But it makes more sense than
talking about objects in the same way as c or Pascal. So each widget would
be a turtle with a name. People new to programming could really identify
with all that.

Maybe if the turtles were defined in a similar way to Oberon modules? That
seems fairly easy to understand and implement.

This is the biggest hurdle, after that something can be coded. It should be
a fairly simple job with GTK given that we have the interpreter already. It
would just need a bit of modification.

I wouldn't want to lock the language into being centred around a canvas and
a turtle though. It would inhibit real program development and I'd like to
write some real programs with it.  The input window with turtle canvas
should just be an interface written with the logo to introduce the language
to kids.

Roman.