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

Re: Logo





Ian Bicking wrote:

> 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.
>
> 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.

Well said here I think. It's good for exploring many aspects of control
technology as well. Something Metacard can't do unless you programmed it to.
But then you'd be writing something like logo anyway. :)

>
>
> 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.

Every school in England uses logo - that makes 32000+ installed base. I
don't know of any of them using Metacard and I doubt very much that any of
them will. I think Scott has to be careful here and think about the world
market and not just the USA. Seul-edu is concerned with anyone using Linux
and that includes all nations and all pockets. Metcard for example is way
too expensive for your average Linux developer to use.

> 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.
>

Exactly.

> > 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.
>

I should think I'm interested in writing a logo because I'd like to. Isn't
that the point. Scratching an itch and all that.

My concern with a product such as Metacard is that it cannot be used in an
Open source model. Not that I think everything should be open source but I
believe that development tools should be. I wouldn't want to persuade the
Metacard people to open their product. My problem there is that if I develop
something with Metacard then should anyone wish to improve it for the good
of everyone, they'd be forced to pay a licence for Metacard and if they were
just your average developer that licence could well cost them nearly $1000.
So my software couldn't benefit from the bazaar. I won't be using it.

What maybe I'd rather see is a slightly different licence whereby free
software developers could buy the product at the K-12 price but if they
wanted to commercially exploit their stacks they'd pay the higher price. I
think that may be a slightly more practical pricing model and a one that I'd
go for. For example, I could develop some free software here and after using
it in a real application like that may decide to use it for one of my
clients. Should that occur then I could justify spending the extra money on
it.

That said, I would never want to tell anyone not to buy it. I'm sure it
would be a very useful addition to any school's software library.

Roman.