>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
>
>http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html
>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 
>development

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

"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 
programming language.

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 
anymore).

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 
always behind.

>== 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 
opinion.

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

Thanks,
JJ

_________________________________________________________________
Type your favorite song.  Get a customized station.  Try MSN Radio powered 
by Pandora. http://radio.msn.com/?icid=T002MSN03A07001