Sorry les. In trying to keep it short I erred in accuracy. If ever I need to
defend Smalltalk I'll draw on your material below. Thanks
I did really mean Smalltalk in general.
I should have defined my understanding of perfection:
I hold one view that some things start with perfection (intent) and end up
better or worse.
I also hold the view that some things start with imperfection and (by event
rather than intent ~accident) end up better or worse.
And another view that either way nature (perfection-in-itself) wins.  I like
all the views.
Poor creatures that we are, logic (an imperfect technique) is all we have
got to work with. The rest is an act of faith I guess.
Upon reading the Smalltalk author closely:
In this particular case I strongly believe the author achieved all above
views very much by intent.
And the evidence of that intent lies hidden deep in the very heart and
concept of Dynabook itself as an (perfect for a child), and (as first
principle) IDE.
Not as in a (perfect for an adult) and (as first principle)  Integrated
Operational Environment; IOE.
The only evidence I have to offer is the number of "children" that "parent"
Smalltalk has spawned over the years. Is it really all just so much
speculation? I don't think so.
Whether one sees IDE Smalltalk as containing all the possible Objects
(concepts and principles) one might ever need to develop already,  or
whether one must (from Smalltalk) call on the external world for assistance
is a matter of CHOICE offered by the IDE: it works for some and not for
others but, so far it seems to have consistantly worked for the Author.

Two words keep coming to mind: Safety and Freedom. Therein lies Smalltalks
perfection.
I liken the author to a great artist of proven talent and technique who in
the last few decades of his life endeavours to paint with the innocence
(perfection) of a child. Therin lies the secret.

Now another type of user is becoming aware of Smalltalks power as an IOE.
Must the original perfection be simply pushed aside?  Hmmm, problems or
challenges? Perhaps the Author knows.

----- Original Message -----
From: "Les Tyrrell" <tyrrell at canis.uiuc.edu>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, January 19, 2002 4:31 AM
Subject: Re: [FYI] Java vs Squeak/Smalltalk


>
> ----- 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
>
>
>
>