Jython vs Squeak for teaching multimedia

Alan Kay Alan.Kay at squeakland.org
Thu Jul 4 18:23:55 UTC 2002


Mark --

At 9:46 AM -0400 7/4/02, Mark Guzdial wrote:
>On Wednesday, July 3, 2002, at 11:41  PM, Roger Whitney wrote:
>>I think the reason objects and classes may be avoided in intro 
>>classes is that the people who teach them think objects are too 
>>complex for students.
>>
>I once asked Alan Kay what kind of language/programming should be 
>taught in a first course in a University.  (Alan, please do correct 
>me if I'm mis-remembering your answer.)  He suggested that students 
>should NOT first be taught object-oriented programming. 
>Object-oriented programming is hard, on purpose, he said.  It's 
>meant to produce good, reusable code.  That takes some discipline.

It must be someone else you are thinking of. I've never taught 
children anything but OOP. I don't think adults or children who have 
*never* programmed are challenged in the least by OOP. But the first 
paradigm that one learns seems to have quite a lasting effect these 
days. It was easier in the early sixties when I learned to program 
because there were no orthodox machine or language architectures, and 
one had to learn at least 20 or so. This helped quite a bit when a 
new idea came along (it was just another new idea, why not learn it 
too?) .... By the end of the sixties, all had changed, and data 
structures and procedures had quite taken over.

>
>That doesn't mean that first-time students shouldn't program WITH 
>objects.  E-toys are all about objects, and that makes life easier. 
>But E-toys-using students aren't dealing with class definitions and 
>instance/class distinctions and all those other things that make 
>object-oriented programs high-quality, but are fairly hard things to 
>learn.

Well, I think this is a confusion with "objects" and some of today's 
"object-oriented systems". In the "Early History of Smalltalk" paper 
I wrote back in '93, I seem to remember pointing out that the first 
three principles of objects that came to me in '66:
   * Everything is an object
   * Objects communicate by sending messages (which thus must be objects)
   * Objects can remember (memory thus via objects)
had stood the test of time. In fact the most annoying properties of 
today's Smalltalk/Squeak stem from the parts that haven't been 
completely objectified.
      The second comment was that the generalizations of descriptions 
were constantly in flux, and were thus not yet in some fundamental 
form. In other words, the various ways to classify was not deemed to 
be in any above threshold form, and this constituted a real problem 
yet to be solved for OOP.

For example, ST-72 didn't have subclassing because I didn't like the 
nonmath way that Simula did it. However, various such schemes could 
be done by a form of delegation. I think the slight generalization of 
Simula's class inheritance that ST-76 adopted solved a short term 
problem pretty well, but ultimately introduced more potential (and 
now actual) complexity than it was worth. Henry Lieberman wrote a 
very nice paper years ago about delegation and protoyping. I think 
this is a better path than today's Smalltalk. But, Henry's solution 
was also too slippery with regards to how meaning was abstracted. 
SELF also had some good ideas, but, to me, was too "LISPY" with 
regard to dynamic changes of meaning.
      The etoys has its own object model -- basically testing a 
"universal object mulitple perspective" design -- and will someday 
find a better notion of generalization than Smalltalk, Actors, SELF, 
etc. The main thing to learn here is that you can do a hell of a lot 
with a suitable conception of a universal object made from multiple 
perspectives, certainly more than enough to get through a one 
semester course for nonmajors.

So, here's what I think today. If you are going to teach objects at 
all, then you should teach them right from the beginning, or pretty 
much forget about it. And the objects should not remotely be abstract 
data types. Every effort should be made to model things that are more 
interesting than data (that's pretty much everything in the universe! 
-- so there is quite a large selection to choose from).
      If your OOP system shows too much mechanism for beginners, then 
use it to reshape itself to show beginners what they need to see: a 
nice combination of simplicity and power. If your object system 
doesn't readily allow this reshaping, then you should abandon it and 
find one that does (why teach something that is ultimately not 
sound?). BTW, this is a good way for students, especially grad 
students, to learn deep ideas about language and systems. They should 
be readily be helping to make forms of the language for the beginning 
classes.
      For example, I am astounded that folks who teach Squeak in 
college haven't done a lot more to make an introductory environment 
that gets beginners quickly into the many media objects in Squeak. 
This would be analogous to what we did with the etoys for children, 
but with more range.
      I don't think that the whole apparatus of the tile scripting is 
required, but making viewers that really show powerful abstractions 
of the media objects is really important. Making some kind of 
extended scripting syntax -- maybe even Python or Lingo-like, if that 
is the taste -- is a very important part of this. Making methods that 
easily run in parallel (as in the etoys) is a very good idea, etc. 
All the apparatus is there in Squeak. Why can't the grad students 
learn to use it and make some scripting environments that help 
college students? (Where's the beef here? I mean, this is what grad 
students used to have to learn. Do they no longer have to know how to 
make a language that compiles into polish byte codes?)
      It's not a good excuse to say that the existing Squeak compiler 
is an overly complicated tangle, because there is no reason not to 
make a simpler compiler -- even a teaching compiler -- for the 
purposes  of helping beginners that doesn't have as many 
optimizations -- and in fact, most of the optimizations in Squeak 
come after the simple parse tree is constructed, etc.

>
>Alan's suggestion (which he re-iterated at the MM in CS Ed workshop, 
>http://coweb.cc.gatech.edu/mmworkshop) is that a first programming 
>course should be in multiple languages so that students don't latch 
>on to only one way of thinking.  I've heard him propose assembly 
>language and LISP as giving students two ends of a spectrum.

I do think learning multiple ways to program over one's first year is 
really important. I don't think any of the current paradigms 
(including ours) is strong or comprehensive enough to serve solely as 
the first imprint.
      But timing is everything here. One way to do this in college 
would be to have a two semester sequence over a year. Perhaps the 
idea of the first semester is to get fluent in something pretty darn 
powerful -- such as a suitably prepared version of Squeak as alluded 
to above. In the second semester other styles could be explored -- 
and many of them could be in Squeak as well (but perhaps not all). 
Perhaps the mix of other styles should start earlier. It would be a 
very good and important experiment to find out. This experiment would 
be good for NSFers interesting in making things better to fund.
      Here is a partial list of styles:
   * The mapping of simple OOP programming to massively distributed 
systems is really important. For example, Squeak has a nice 
implementation of Mitchel Resnick's StarLogo that allows a lot of 
"heavy zen" to be experienced pretty easily.
   * For example, the APL "mapping style", which we also find in a 
recursive form in LISP and in functional languages has some nice 
benefits. All of these styles are either in Squeak now, or are close 
to being there.
   * "Logical variable" programming, as in Prolog, etc., is very important.
   * Also, the relationship of forward inferencing to event-driven 
programming is important, and of  these to retrieval programming, and 
of these to certain kinds of coordination matching (such as LINDA). 
There have been many different versions of this in Squeak, but none 
smooth enough for college beginners. But what students need is within 
the range of what a good grad student can do.
   * "Massively distributed systems futures programming" such as the 
Dave Reed stuff we have been experimenting with is tremendously 
interesting. The relationship of this to certain kinds of "possible 
worlds" AI programming is very interesting. We will put this out to 
the Squeak list in the Fall, and I think most will find it to be 
interesting, if not astounding.
   * I think at the end of the year, it could be very interesting to 
bootstrap up a simple LISP or Smalltalk from raw machine code and a 
"fast-track" tool. The whole point of what John McCarthy and Steve 
Russell did is that great power could come from a rudimentary CPU + a 
small amount of code with a powerful mathematical architeture. The 
same goes for Smalltalk, which had a somewhat similar history, with 
Dan Ingalls playing the central "make the BS real" role. (P.S. 30th 
anniversary of this in September this year; surely everyone knows how 
to do this by now ...?)

This stuff is too important to be left to the vendors. I don't think 
settling for a compromise is good enough in any computer science 
department that is proud enough to confer degrees. The latter should 
mean there are real computer scientists among the profs and grad 
students -- and one of the measures of this is whether they can make 
the environments they want and need, especially with today's fabulous 
resources.

Cheers,

Alan

Cheers,

Alan

-- 



More information about the Squeak-dev mailing list