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
|