> I'm not trying to say you're a fool.  It is great that this 
> method works for you.  But do you want Smalltalk to be for 
> people who tinker or do you want a larger user base?  Larger 
> user base buys you more bodies to write code so things get 
> done faster, new killer apps get made.
> It also buys you more testers and potential bug fixers.

I don't measure success by the number of people using Smalltalk.
Personally, I want Smalltalk to be for people who grok Smalltalk, not for
people who want to make it more popular by making it more like everything
else.  Smalltalk rocks precisely because it's not like everything else, and
that includes what is considered programmer documentation.  Self documenting
code is a style, one smalltalkers prefer, that and some unit tests, are the
best documents there are.

> I just don't find "code is the documentation" acceptable at a 
> professional level.  Open software tried to say that in the 

Ok, maybe you don't, but many others do.  There's lot's of stuff being done
out there in Smalltalk land with little or no "formal" documentation.
Documentation the way you define it, simply isn't necessary for success,
maybe it's necessary for mass accpetance, but acceptance and success are
different things.  Smalltalk is already successful, and growing more so
every day.

> But if my company has millions of dollars riding on your 
> software there had better be some documentation.

That's an opinion, not a fact, but there's plenty of code out there running
on Squeak, and very little if any formal documentation.  Success depends on
people, not paperwork.  You'd be trusting millions of dollars to a person,
or a team of people, not some papers.

> Do really think it would be ok to deliver a product to a 
> customer and say "well, the code is all there, dig around and 
> you should be able to figure out how it works in no time"?

I thought we were talking about documenting code for programmers, not user
documents for products.  Was I mistaken?