----- Original Message -----
From: Justin Walsh <jwalsh at bigpond.net.au>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, January 16, 2002 9:47 AM
Subject: Re: [FYI] Java vs Squeak/Smalltalk

( picking and choosing here... )

> Hi and thanks Bijan!
> I'm one who enjoys just watching and listening to Smalltalk developers and
> hackers go about their important business using what is truly the best
> Integrated Development Environtment ever devised.

Hmm... actually, I have other preferences ( but they are other Smalltalks ).
There are no serious deficiencies, but even the "little" things make a big
difference at times.

> The attention should be returned, first and foremost, to the term IDE, the
> fundational concept (object-ive) upon which St. was developed in the first
> place and  then, and only then, turned to the predication of IDE by six
> secondary concepts of Encapsulation, Class , Polymorphism Objects,
> (forgotten the others).

I don't feel that the IDE is the primal thing in Squeak.  See below...

>  It's blessing is and I hope remains, it's purity.

A very important point.   The one hardest to convey to those who keep creating
other languages which borrow heavily from Smalltalk, but seem to keep missing
its essence.

[snip]

> Philosophically and Technically and, keeping concept IDE squarely in mind,
> St. is without a doubt, as close to perfect an IDE as it can possibly get.

To play devil's advocate: The Squeak IDE is pretty good, but I don't want to
rate it as being "nearly perfect".   That would indicate that there is no
further attention needed in this area, which I don't believe.  I feel there is
still room to make it much better.  Which is NOT to say that I see there being
any significant obstacles to such development- I don't believe that this would
require fundamental shifts in paradigm.  But being pretty good, even better
than many other IDE's,.  should not be confused with being "as good as
possible".  We don't know what that would be yet.

> Given the circumstances of it's creation of course.
> Most of the literature that I have read on history of Java, for example,
> describes it as having been derived from Smalltalk along with such things as
> objects, windows, ethernet etc.
> Every other IDE, irrespective of how good it may be to the user, and how
> clever it might be in detail, remains merely an after-thought:

Larry Tesler had a nice quote about that, which I'm paraphrasing: "No user
interface, no matter how cleverly constructed, can hide a poorly designed
system."   Ugly shows, no matter what.

> Smalltalk is the product of design first not merely a desire.

An exceptionally important point, though to be fair Smalltalk evolved over a
10 year period in a somewhat protected environment before being subjected to
market forces.  Nonetheless, a number of important design decisions were made
that are sometimes not as strongly appreciated as they deserve.  Most of those
decisions are independent of the IDE, but they do have a very strong impact on
the impression that the IDE is very good- the IDE gets a tremendous boost from
the normal Smalltalk runtime that it lives in.  Most of its capabilities come
easily as a direct result of the character of the runtime.  Some examples:

Everything is an object ( no primitive types which are not objects ).
Therefore, no need to understand language constructs which separate the
two.  As far as the programmer is concerned, there is nothing in the
environment which appears to be of a fundamentally different character from
everything else.

Therefore, even classes are objects, and interaction and use of classes
again does not involve specialized language constructs to distinguish classes
and instances.  All objects are instances, its just that some of them also
define behavior for others.

Therefore, processes are also objects, yada yada yada.  We interact
with Blocks in the same manner as we interact with other objects, sending them
messages.  Because we can do this, we can do program control by sending
messages to blocks, rather than having specialized language constructs for
things like if/then/else, while/do, etc.  And so we do.

Therefore, there is only one "type" of thing - all things are Objects.
Not int's, unsigned longs, char *'s, etc.  Only Objects.
Thus the VM deals with a very simple set of structures as it
manipulates the objects in the runtime.  Our development tools are therefore
much simpler, since there is a very simple structure to all objects.

All instance variables are private, always.  Therefore it is never possible
for objects to directly change the state of other objects.  They must always
interact with other objects through message sending.  Therefore, there are no
special language constructs to distinguish between message sending and
directly accessing another object's state because you can never do the latter.

We always interact with objects by sending them messages.  We do not require
that they understand those messages, but do provide a simple mechanism for
handling cases where messages are sent but not understood by the reciever.
Therfore, we safely hold the expectation, not the requirement, that objects
understand the messages we send to them.  Thus, we can allow our code to be in
a partially complete state.  We can always send any message to any object, and
it will either understand it or not, but both cases are always handled.  There
are only two cases that need to be handled.

Therefore we as programmers do not worry about creating many variations
of the same method in order to handle differing argument types.  We only
expect our arguments to respond to certain messages.  We may be wrong, but we
do not need to create differing versions of the same method to correct this
expectation.

All objects respond to messages that they understand by answering an object.
( In Concurrent St this semantic is deliberately changed to allow distributed
asynchronous message sending between objects in different environments ).
That object may be the reciever, nil, or any other object.  But in all cases
these are objects, and we interact with all objects in exactly the same way by
sending whatever messages to them that we think they will understand ( or
not ).


> This is just my boring opinion and not worth arguing about.

Actually, there are some important points worth discussing about why Smalltalk
is the way it is, and why that has such an important impact on why we feel so
strongly that it is a very good system.

- les