[Squeakland] Logo vs. Squeak

Anindita anindita at media.mit.edu
Sat Aug 9 12:55:12 PDT 2003

I've worked with both Logo and Squeak and my research group has been
having a lot of Logo/Squeak discussions lately. I'm with the Future of
Learning Group at the MIT Media Lab, and recently I've had the great
opportunity to work with John Maloney on Squeak after a year and a half of
plowing through it on my own. I've also had a number of conversations with
Seymour about Logo and Squeak.

My quick critique of Squeak is that there are a number of great things
about it, but it doesn't meet its potential. It's completely
object-oriented, allows children to program many different types of media
and one of the biggest selling points for me-- it's open-source. It's free
for schools to use and developers and teachers can make all sorts of
modifications. This has been really helpful in projects that I've done.
Logo is lacking here. I've mostly used Microworlds Logo or Imagine. What I
find frustrating is that the only object is a turtle. This is great for
the geometry microwold for which Logo was designed. It's a very elegant
language and environment. But it isn't very extensible, either to
different forms of media, or to communicating with hardware-- both of
which are simple tasks in Squeak.

There are a few big problems with Etoys, however. The biggest one, in my
opinion, is that it completely limits the object-orientedness of Squeak.
In Etoys, one cannot create a new class of objects-- just new instances of
objects. I can create and program an object, then copy it so that it has
the same characteristics, but I cannot define a class, then create and/or
modify instances. Logo gives more flexibility in working with the turtle
object. Also, complex code is possible in Etoys, but it gets pretty ugly
quickly (this could also be because I haven't been using Etoys nearly as
long as I've programmed in other languages-- I'm sure Alan's Etoys code is
much simpler than mine!). Then there are basic interface problems. A lot
of people (children and adults) with whom I've worked have been very
frustrated with the drag and drop tiles. The tiles don't drop where they
want them to and create new scripts or fall into the wrong slot. . . the
green square doesn't help them very much. It's also hard to know what to
do when the environment is opened. My first impulse would not be to
alt-left click an object to pull up a halo and then click the blue eyeball
to pull up one object's viewer at a time. Everytime I explain this
process, people just look at me or ask "And who came up with THAT?"

Squeak is powerful and flexible. I love working in it since I can easily
do things that are difficult in Logo (especially since one cannot access
the Lisp language underneath it in the commercial versions). Etoys is good
for a number of activities such as simulations and animation, but in later
versions of Squeak, it's been getting more bloated instead of more
refined. Many more tiles have been added in and it's hard to navigate.

At this point, it might be good to take a step back and rethink how to do
scripting in Squeak so that children can access the powerful ideas and
flexibility of Smalltalk more simply. Just as Logo serves as a simplified
Lisp, there could be a simplified Smalltalk for children to use. Ken
raises some good points about using icons. The two could also be combined,
as Alan stated.

Right now, there are tiles in Etoys and scripts have two sides: tiles and
text. The text is simplified Squeak code and the tiles could easily be
turned into icons, giving two modes of programming. But the larger part is
to think about what primitives children need in the environment, and if
they need all of them up front in a viewer, or if there can be layers of
complexity added in. How can one transition from being an Etoys programmer
to a Smalltalk programmer? Right now, the gap is rather wide, but ideally,
the ceiling should be that high.


More information about the Squeakland mailing list