Actually Mark, you would be at the top of my list to write and/or 
organize the new book in question. Another would be Randall Schwartz 
... Or ...  heh heh ...

Just to say it again, I think that at this point in time it is worth 
creating and freezing a documentable version of Squeak.  Although 
there are always lots of improvements, it's pretty clear that some 
solid documentation and cleanup that would allow Squeakers to easily 
make things like what I show in my "flagship" demos would be very 
very useful to most people, and would help them get into the rest of 
the system.

Cheers,

Alan

At 4:52 PM -0400 4/16/02, Mark Guzdial wrote:
>On Tuesday, April 16, 2002, at 02:55  PM, Cees de Groot wrote:
>
>>Alan Kay <Alan.Kay at squeakland.org> said:
>>>Well, I think a rounded off cut a la "Stable Squeak" should be the
>>>target, but with a nice list of minimal criteria for coverage of
>>>multimedia, UI, etc. I'm sure that Ruby and REBOL continue to
>>>progress, but just not as much out in the open as on the Squeak list.
>>>This is where a "Stable Squeak" or "Squeak Foundation" would really
>>>help, namely to put out a real release that satisfies "a list" and
>>>that then can have a useful subset documented.
>>>
>>Even without SqueakF, a companion site could hold The Official Version
>>With The Book for all platforms. Between writing and publication, you'd
>>have a couple of months of testing, polishing, and making sure that a
>>really good version is made available there.
>
>I tried that strategy with the White book.  It contains a CD with 
>Squeak 2.7 and 2.8, and all examples are guaranteed to work there. 
>But most hobbyists will go directly to Squeak.Org and download the 
>Latest, which can't be guaranteed to work with anything written on 
>dead trees.
>
>>
>>Furthermore, I think that a teaching (oops: learning) and reference
>>book on Squeak would have lots of stable places: Smalltalk seems to be
>>reasonably stable; if you've been taught the basics of EToys you wont'
>>really be surprised at what turns up in a later image. Also, it would
>>be relatively easy to plan writing according to a volatility scale, so
>>the stuff that's most likely to change is done latest (starting with,
>>say,  chapters on "history", "objects", "smalltalk the language" etcetera)
>>
>The issue isn't that the base of Smalltalk is relatively stable. 
>The issue is that motivating examples tend to get built with the 
>higher level code, which DOES still change.
>
>Mark


--