From: "Paul D. Fernhout" pdfernhout@kurtz-fernhout.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@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