[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Logo



Scott Raney <raney@metacard.com> wrote:
[snip]
> As for Logo, I must say that I have a pretty low opinion of it, an
> opinion shared by everyone I've ever communicated with that knows both
> an xTalk dialect (e.g., the HyperTalk language used in HyperCard,
> SuperTalk in SuperCard, or MetaTalk in MetaCard) and Logo.  Logo was
> designed by Lisp programmers a long, long time ago, and decisions made
> in its design probably made sense back then but are really out of
> place in today's computing environment.  For one thing, xTalk is so
> much easier to learn than Logo, a key factor when trying to introduce
> kids to programming.  And in addition to drawing tools, xTalk has
> fully integrated widget support, which is crucial for any non-trivial
> programming task.

Is there anyplace where I can read a more technical/formal 
description of one of the *Talk languages?  I've never used them, 
and the recent experience with MetaTalk has only left me a bit 
mystified.  In mimicking English it seems to leave out some 
regularity -- but maybe I just haven't seen what the underlying rules 
are.


But I think we're talking about two things here (though in the same 
thread).  There's the authoring system, but there is also a 
programming environment.  To the degree MetaCard or even 
HyperStudio is a programming environment, it is *much* different 
from Logo.

I think Logo is much more appropriate for teaching programming 
from a mathematic/algorithmic perspective.  It is quite formal and 
minimalistic with few special forms, lends itself to a substitution 
model fairly easily, is based on procedures instead of messages... 
it's a lot like math.

It's not object-oriented, and I don't really think it should be.  That 
might be a good paradigm, but the various attempt to paste OO 
onto Lisp languages that I've seen is rather unsightly, even though 
it can be effective.

Logo has a significant history to it, with many books and 
curriculums.  I haven't seen this happen much at all with the *Talk 
languages, though perhaps such things exist -- I must admit I 
haven't actively looked for such things.  Logo was designed very 
much for pedagogy, but the *Talk languages seem more about 
functionality and ease of learning.  Those are different ideals.  Logo 
has lots of abreviations because little kids type very very slowly... 
is MetaTalk sensitive to those sorts of problems?  It seems like it's 
intended for more literate audiences than Logo.

Anyway, I think the *Talk environments and Logo environments are 
coming from very different directions, both of which have a purpose. 
Perhaps one of them will be able to move to span both ideals, but I 
don't think I've seen that happen yet.

> There is only one justification that I can see for including Logo in a
> Linux-for-K12 project, and that is if 100% compatibility with
> HyperStudio is a goal.  But this is probably not an achievable goal,
> and indeed is probably not even desirable.  

I don't think we are even considering such a thing.  *Maybe* we'll 
have something that looks and acts somewhat like HyperStudio, at 
least on the level that a regular student uses it.

In part it's important to have the niche that HyperStudio fills to also 
be filled on Linux, one way or another.  More strategically, it would 
be nice if teachers could translate their HyperStudio knowledge to 
the new environment.

> Logo is very well hidden
> in HyperStudio, and in my recent research of the matter in the local
> schools, I didn't find a single teacher who used HyperStudio that had
> anything more than name-recognition for HyperLogo.  Of course, none of
> them taught it to their students.  And from following the Logo and
> HyperStudio mailing lists for the past several years, my considered
> opinion is that the number of teachers using HyperLogo in any district
> is vanishingly small.

I don't think HyperLogo has been very successful.  It's kind of 
peripheral to HyperStudio, has a rather crufty interface, and is a 
pretty poor implementation of Logo.  Not to speak too badly of 
HyperLogo, but it's never been a serious part of HyperStudio, and it 
shows.

> I do believe that HyperStudio compatibility *is* an important goal,
> however.  But only at the user-interface level.  That is, teachers and
> students should be able to pick a compatible product and know how to
> navigate through the dialogs, how to paint things on the screen, and
> how to save resulting project.  This is where MetaCard comes in: since
> it has the same basic infrastructure as HyperStudio (card/scripting),
> and is a full-fledged development enviroment, building a
> HyperStudio-like interface for it would be an exceedingly easy thing
> to do.  It would take maybe 20% of the effort of building a similar
> package in Tcl/Tk, and probably less than 5% of the effort of building
> something like this in Java or C + GTK/Qt/whatever.  This kind of
> productivity advantage would almost certainly be the difference
> between getting a project like this finished and having it die out
> after talking about it for a few weeks.

From the little I've looked at MetaCard, it does look like a 
HyperStudio-like interface would be pretty easy to set up.  Mostly 
a matter of taking away the flexibility and number of options of 
MetaCard and making it a bit more modal.  Is there something for 
bitmap painting set up in MetaCard, for painted backgrounds like 
HyperStudio has?


--
Ian Bicking <bickiia@earlham.edu>