I think that this whole discussion is rather dreadful.

No one has answered the first obvious question: When someone wants to
'learn' Squeak, and what does that mean? Hopefully this leads directly to
'How do we teach Squeak?'

Reading through the list over the last few years, I've noticed that we have
different categories of 'newbies' what want to learn Squeak.

First, we have the legitimate newbie, that is, someone has never programmed
before.
Second, we have people who have had exposure to what I'll call politely more
traditional languages ( C, C++, Java, etc) who are rather baffled about the
concepts and execution of the Squeak ideal.
Third, we have people who are experienced programmers who want to learn
Squeak at what I'll call the 'system level'. Typically these people arrive
on the list and have very specific questions about issues that are very
closely related to programming the metal, such as how to control sockets and
filestreams, different stack protocols, compiling the VM, etc. (As an aside,
it seems to me that a lot of the questions have to do with how to do this or
that under Linux. It's a shame that these technically savvy users are having
such a hard time just getting Squeak to run properly on their machines, more
or less actually program with Squeak. This is something that seriously needs
to be addressed).

This is all rather strange. The base of the Squeak image has been documented
in several ways, entire *books* have been written about it, from the
original blue book to Guzdials new books. Yet people say that Squeak  is not
documented, and other more trivial languages have 'extensive documentation'.
Give me a break.

As you can guess from my previous writings, I have a different opinion. All
of this 'documentation issue' is nonsense.

Truth is, I'm convinced we don't know how to teach programming. We pretty
much learn to program by example. For me, I received a degree in computer
science. As I hazily recall, some nefarious looking characters stood up in
the front of class and taught us how to write basic constructs such as
procedure calls and loops and so forth in a variety of different languages.
We studied the teachings of Knuth and other gods. The major tool used in
these teachings was a piece of chalk no less. We'd go to the machine labs
and write our simple little programs and turn them in. They would be graded
based on one, if they ran correctly over the entire range of data, and two,
if they were *properly* documented. Such programs were on the order of
100-500 lines of newly created code.

I happily graduated, and took a job. My first assignment was to work on
maintaining a legacy system that was lying about. Five million lines of code
that had to run in "real time". About a month into the job, I began
wondering if an alcholic lifestyle was really all that bad. My guess is that
'learning the language' of the implementation is insignificant in relation
to understanding the interaction of different parts of a specific
application. I would submit that 'learning Squeak' is really a two fold
process, learning the language and understanding a basic subset of the
image.

Every time that I've had to learn a new programming language, it's been
invariably the same. I read some introductory text that glosses over the use
of the new miracle language, grab a simple example and try to get it to work
by installing the development environment and compiling the source code. It
is rarely as straightforward as one would hope, especially these days with
the advent of net distribution and its attendant versioning problems (Yeah,
it works if you use library version 3.013b2 instead of 3.013a37, that sort
of thing). The big moment finally comes when I try to change the source code
to actually do something else. I've found that it usually *does* do
something else, just not what I had intended. Eventually, I try to do
something specific in the new language, like make an HTTP request. I try to
find a code snippet somewhere, use that as a base to start from, and slowly
build upon that. What it means for me to learn a new language is probably
quite different from a complete computer neophyte.

OK, what does that have to do with Squeak?

Let's address the true newbie first. They need to learn programming at a
different level, like a version of Etoys more or less before moving on to
true Squeak. That is a hard case, with no easy answer at this point.

In the other cases, there is the traditional solution. Throw 'em into the
deep end, and make 'em swim. If they can't, tough luck. The good thing about
Squeak is that all of the source is included, and if you get Squeak running
on your machine you have all the examples included. In most any other
language, you don't even get that much. Once you get past, "Here's the
environment, here's how to run your code, use the editors, and here's some
useful tools", you're pretty much on your own. No amount of dead trees are
going to help you very much past this point.

By its very nature, Squeak is pretty much like programming on top of
quicksand. There is no backwards compatiblity between versions, so while you
may be able to go through the books and learn the basics, this by no means
makes you fluent in the language (or more precisely 'image fluent'). We've
seen this with the online tutorials and such that people have written that
are outdated within a small amount of time. I've personally experienced this
with much of the code that I have written over the last couple of years that
doesn't run on the newer versions of Squeak. This is usually due to the fact
that there really is no morphic base system (and therefore screen I/O), as
morphic has been late to mature.

The other type of solution is to provide system tools for exploring the
system, like the Method Finder. That's a pretty cool idea, and something
that most other languages don't provide. These types of tools could be
beefed up a bit with by borrowing a few ideas here and there from other
development environments. For example, it would be nice to be able to set
breakpoints with out adding 'self halt' in the middle of a method. InstVar
and Variable monitoring would be extremely useful also, e.g., tell me when
this InstVar gets set (or set to a particular value) and who did it. In
general, Squeak is pretty good in the available tools regard.

What is painfully lacking is any sense of overview of how subsystems and
different classes fit together. There really should be a way to describe the
subsystem architecture in a uniform way. The simple hierarchical browsers
are overly simplistic. I haven't been able to figure out a suitable solution
here. Due to the dynamic nature of Squeak, there is obviously no 'correct'
way to heuristically describe these subsystems at compile time, and indeed
they may change at run time.

>From what I recall from the list, typically the newbie comes to the list
asking for help as a first resort. The swiki should be a prime source of
answers for most of the questions being asked, but it does not seem to be
utilized to as much as it should be. This should be fixed.

To me, the Squeak image itself should be the source of the documentation
answers. People should be able to ask the image to teach them how to use it.
Unfortunately, it's been so long since I've been a newbie, that I don't
remember what type of things the image needs to teach people in order to get
them to 'learn' Squeak.

Jim

PS: I wish everyone would quit feeding the Justin-bot.