I'd like to add that a really good way is to have the example class methods similar to 
what exists in the pen classes. Then you get to see the classes work and how they work 
and how they are coded.

Perhaps my favourite way of learning is to decide on a programme to write and then dig 
around to see hot to do it using various info resources. The example class methods are 
very helpful where they exist.

Gary

19/01/02 23:57:40, "Andreas Raab" <Andreas.Raab at gmx.de> wrote:

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