Les,

> However, I do sometimes feel that in other ways I had an 
> advantage over today's newcomers- V/DOS only had about 90
> classes visible to the programmer. V/286 ( I believe ) had
> fewer than 300.  It was *much* easier to get a grasp of the
> important, useful classes in such a smaller system.  I 
> would not want to learn by wading through the thousands of
> classes that are more typical now, wondering which of those
> many hundreds of classes are *really* essential to
> getting things done for the problems I want to solve.   In 
> that sense, I could believe that learning Smalltalk has
> become much harder.

I think that's a very valid point. But the issue is not so much the
thousands of classes - it's much more the lack of structuring towards
problem domains. E.g., in order to do some hacking in bitmap, vector, 3D
graphics, sound synthesis, network communication, application
programming, etc. etc. etc. you don't need to learn more than a hundred
classes. The question that we don't have a particularly good answer for
are _which_ hundred classes we're talking about and what you need to do
for integrating this stuff easily into the "rest of the world". (insofar
I disagree with Alan's idea about a 100 classes to do "most" things -
there is plenty of interesting ground that cannot be easily covered in
those 100 classes; I would rather like to see a "problem oriented"
filtering which gives one a nice, easy road into different areas)

As an example, to do some fun stuff with graphics, all you need to know
about are roughly twenty classes (Form, BitBlt, Color, Point, Rectangle,
Number and very few others). But go figure where they are.
"Kernel-Objects" alone has fifteen classes out of which I would say that
only three are truly essential (namely Object, Boolean, and
UndefinedObject). Now go looking at Number (which incorporates the
essential concepts) and you will find six classes which - in the end -
represent only specific implementations of the same concept.

And then, even if you did learn about these concepts and even if you
know how to do a bit of graphics hacking there's the question of how to
integrate it. It's just no fun to give demos from work spaces; people
would like to add some sort of user interface to it. And there's
_nothing_ that allows a quick hack to be integrated into Morphic easily.
What would be needed here are some sort of "demo-shells" that ought to
bundled with the domain specific categories in order to teach people how
to quickly integrate their results into the existing world. Graphics is
an excellent example for this - we have no generic CanvasMorph which you
could just use to draw right on some morph's surface. So you go looking
at Morph and -again- end up with the question which of those 1431
methods (Morph selectors size + Object selectors size) are actually
useful.

Cheers,
  - Andreas