On Mon, 22 Nov 1999, Graham Telfer wrote:

> I too like to have documentation ready to hand. I'm not interested in
> tinkering with Squeak. I want to write applications and know what is
available
> to me as a programmer: as is.
>
> I want to be able to accept the library routines with confidence. A lot
of the
> post in this mailing list makes me feel uneasy about the quality of
code. The
> post makes Squeak appear to be like a rusty bucket; full of holes. I
can't
> write code for clients if I can't rely on the language.

The code isn't low quality, but it is still sort of in a state of flux,
because Squeak isn't mature.  If you're looking for a completely mature
language today, look somewhere else.  But this is gradually getting
better, and it sounds like the documentation situation will get better
too.

> > Just want to point out that it's a Squeakish (and Smalltalkish)
philosophy
> > that there *is no hood* to tinker under. That's the "transparency"
goal.
> > Naturally, it's not quite there yet ; [snip]
>
> I used to write a lot of stuff in Forth. Now, there's a minimalist and
> transparent  language for you! In fact it is so minimalist you are
forced to
> write a lot, that in other languages is taken for granted.  It leads to
Forth
> being accused of being a write only language and one that is not easily
> maintainable because (whether you like it or not) an application becomes
> bespoke.

I think in this sense, Squeak (/Smalltalk) is actually the polar opposite
of Forth.  It is definitely *not* a system in which one is encouraged to
write a lot of code to do basic things (e.g. a sorting routine).  The
ideal that is usually held up is to write as small an amount of code as
possible in order to get something done.  And Squeak/Smalltalk is better
at this than, say, C++ or Java or Visual Basic or Forth, especially for
large applications.  (actually, I'm not all that familiar with Forth)

Now, this relatively small amount of code you write might include a couple
of tweaks to classes which are in the base image.  This is the
"tinkering", and it is part of what enables you to write such a small
amount of code in the first place.  Yes, there is potential for trouble
here, but it's not as unmanageable as you might think.

(Also, one reason that tinkering is encouraged at this state is that if
your base image tweaks are truly general-purpose improvements, they can be
submitted to the list for inclusion into the official release!  This will
probably happen less frequently in the future, as things mature.)

> The same thing is likely to happen in Squeak. Encouraging tinkering will
> eventually lead to a fragmentation of the language into unmaintainable,
write
> only bespoke dialects.
>
> > But as Kent Beck likes to say, one learns more by "reading" the
*image*.
> > Good smalltalking involves a high read/write ratio. [snip]
>
> Reading and writing Smalltalk or reading Smalltalk but writing
applications in
> Smalltalk. There's an enormous difference between the two. Which does
Kent
> Beck approve of.?

I'm not sure what you mean here.  But I do know that when Kent Beck
suggests reading the image, that does *not* mean looking for example code
to copy and paste, it means looking for code that you can actually call
directly, reducing the amount of code you need to write.  (And also
learning Smalltalk style from reading existing code.)

> So please, good documentation and accept there is a class of user who
doesn't
> care about Smalltalk per se but only in what can be done with it in an
object
> oriented way.

Good point.  Squeak is slowly becoming more able to support this class of
user, but it's probably not all the way there yet.  If you look back a
year or two, it's already come quite a ways.


- Doug Way
  dway at mat.net

I'd call myself an artist
If I could make these feelings clear
But there's a million things to think about
When you're cutting off your ear
                - Scott Miller