Design Principles Behind Smalltalk, Revisited
azreal1977 at hotmail.com
Tue Dec 26 11:18:26 UTC 2006
>From: "Paul D. Fernhout" <pdfernhout at kurtz-fernhout.com>
>Reply-To: The general-purpose Squeak developers
>list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers
>list<squeak-dev at lists.squeakfoundation.org>
>Subject: Design Principles Behind Smalltalk, Revisited
>Date: Mon, 25 Dec 2006 17:10:47 -0500
>and is intended to help in understanding why, say, Python has been so
>successful in capturing the hearts and minds of the last decade of
One doesn't have to look far for this. C became popular for no other reason
then it was "close enough" and we could use it "right now" to build systems.
The more advanced languages used resources when there were no resources to
"The rise of worse is better" largely misses the point here. The point is:
getting 80% today is infinitely better then 100% "some day". And all the
rest is just the incredible weight of "backward compatibility".
And the concept of backward compatibility isn't just software and hardware.
It extends to workers as well. The average programmer is just not very good
(and I don't speak about the worth of the people as human beings. There are
just so many in the field with no interest in it other then money, which is
totally ok. It just doesn't make for good programmers). The cost of moving
people who are barely keeping up from C++ to Java isn't so bad. It actually
makes things simpler: just the same syntax again with much of what they
didn't understand taken out. But moving these folks away from a C based
syntax is out of the question. And getting rid of them in favor of more
talented programmers would be just as out of the question.
>Again, to contrast with Python, Squeak wants to run the show, but Python
>plays nice with all the other free tools of the GNU/Linux ecosystem.
I keep on seeing this, but it appears largely overstated. Java has it's own
VM, threads etc. as well. And it is easier to connect to the outside world
in Squeak then Java, because in java you are in "your on your own!" land.
In Squeak you always were so there is no need to be afraid of this step if
you need it. In at least Squeak and Dolphin smalltalk you can call "extern
C" style functions directly from smalltalk (thought in squeak you need to
load FFI first). That is at least as good as any of the other languages.
And if you mean more to address the tools, well yes you *can* edit Java code
in vi if you really want to. But no one really wants to. And if your
interface to the language is through some program anyway, then the "barrier"
of the code not being on the file system disappears.
>Forcing everyone to work in Smalltalk using Smalltalk tools, as good as
>they are, means that other innovations developed in other languages with
>other tools, for example, Java, are lost to the Squeak community.
Um... What innovations in Java?
>Many humans become fluent in multiple human languages and their
>accompanying cultures, which is typically a harder thing than learning new
>computer languages. If one needs to switch mental gears conceptually to
>work on the VM, then is it *really* so bad if the VM is written directly in
>C like GNU Smalltalk does?
Typically? It is harder in every case, no matter how badly designed the
And what do you want to gain here? If the squeak community came out today
and said "Ok! You can write the squeak VM in anything you want, we don't
care", they wouldn't suddenly get volunteers knocking the doors down to work
on squeak. They would only lose people who can work on the VM today (not
because these people *can't* do it, but because they wouldn't want to
While I agree that squeak is not required to be written in a subset of
smalltalk, it *is* and changing it wont gain anything. Getting squeak to
run on strong talk might, but I haven't seen anyone forbidding that.
>Right now, I think Squeak on the JVM, like Talks2 is a step towards, could
>be a really big win for the Squeak community, and translating the VM from
>an abstract representation (in Smalltalk) to a specific language is a big
>win there. Still, the VM could have been in any translatable abstraction
>(XML, Lisp, ANTLR parse tree from a VM-specific language, Parrot, etc.) and
>generating Java would still be easily doable (though of course Smalltalk
>encoding is preferable for Smalltalkers).
Java isn't the end-all/be-all here. Microsoft is moving to a more dynamic
VM already, and because of this Java will be forced to as well. Java has
always been behind pre-existing technologies and this area is no different.
If you want to move into the future it is best not to follow a group that is
>== objects are an illusions, but useful ones ===
>In my undergraduate work in psychology I wrote a senior paper in 1985
>entitled: "Why intelligence: Object, Evolution, Stability, and Model" where
>I argued the impression of a world of well-defined objects is an illusion,
>but a useful one. Considered in the context of the section above, we can
>also see that how you parse the world into objects may depend on the
>particular goal you have (reaching your car without being wet) or the
>particular approach you are taking to reaching the goal (either the
>strategy, walking outside, or any helping tool used, like a neural net or
>2D map). Yet, the world is the same, even as what we consider to be an
>"object" may vary from time to time; in one situation "rain" might be an
>object, in another a "rain drop" might be an object, in another the weather
>might be of little interest. So objects are a *convenience* to reaching
>goals (in terms of internal states), not reality (which our best physics
>says is more continuous than anything else in terms of quantum
>probabilities, or at best, more conventionally a particle-wave duality). So
>objects, as tools of thought, then have no meaning apart from the context
>in which we create them -- and the contexts include our viewpoints, our
>goals, our tools, or history, or relations to the community, and so on.
To me this was the most insightful point in the whole essay. Though,
honestly I thought this was pretty well understood. Object Orientation is
simply a way of organizing code in a way that makes sense from the
perspective of the problem domain it is related to. But since programming
is a task of managing complexity, correct organization is a critical piece
of the puzzle.
But this observation is the reason OO databases haven't really taken off:
An OO database will tend to model things how *your* application wants to see
them. A traditional relational DBA will model things in the most generic
way he can so that *all* the applications can build the view they need
easily. Relational DBA's tend to be of the view point: The data will exist
for the life of the company, while the applications that access it come and
go like the tide. And one only needs to look at the huge Java rewrites
going on to know they are right.
>Consider Dan's statement of "A computer language should support the concept
>of "object" and provide a uniform means for referring to the objects in its
>universe." That appears to me to have made a classical mistake of thinking
>the universe has only one parsing into one object hierarchy and that the
>objects exist in some sort of Platonic ideal.
Actually I think this applies more to C++ derived OO languages (e.g. Java).
It is those languages that have huge hierarchies of things that are not that
related due to the brain-dead typing systems. In smalltalk the only
hierarchy that has to be is inheriting from Object. And you don't even have
to do that.
But I think this works just fine: We are choosing to code something, so we
have to model it in the point of view appropriate to how we are going to
solve the problem. And this implies some organization technique. And among
organization techniques, (correct) OO has had the most success in my
><chair part snipped> There is no neat "class" to put it in.
I wouldn't expect it to be in a class. I would expect classes to know how
to stick to each other. :)
>Clearly you, the reader, can think about this entity so the human brain
>supports this fluidity in changing our definitions of objects and not
>requiring a one-to-one mapping to ideal classes to think about them, but a
>computer language like Smalltalk would have many problems representing
>this. William Kent, in the book _Data & Reality_ discusses these sorts of
>problems at length.
I disagree with where the focus is placed here. An entity typically does
have just one name and would make sense to be called one thing in the
system. What you are describing sounds more like interface protocols. This
might be an area that could use more research, but honestly I would want to
know what is bought by formalizing this existing practice more (e.g. making
protocols first class objects themselves or something).
For an example of what I mean, in case it isn't that clear, we could think
about Lists. They have a collection protocol: a series of messages that
conform to what other collections can do. But they could also have a
"stack" protocol: a series of messages for treating the list as though it
were a stack.
This could be seen as what we do in real life. Due to necessity I may find
myself driving a nail into a piece of wood with a screw driver. But I would
never call what is in my hand a hammer. I would simply be using it's "blunt
object" interface momentarily.
Type your favorite song. Get a customized station. Try MSN Radio powered
by Pandora. http://radio.msn.com/?icid=T002MSN03A07001
More information about the Squeak-dev