On Monday, September 27, 1999 5:08 PM, Stephen Pair wrote:
I (Michael Klein) wrote:
Smalltalk chooses a "fixed" point in language desing space that is good for 99+ % of the time. It also gives you all of the powerfull hooks to handle the remaining small amount. (The powerfull hooks are things like Behavior, #doesNotUnderstand:, #become:, thisContext, etc) These are very powerful for building frameworks that allow "ordinary" (99+%) methods to avail themselves of extreme coolness
That same argument could be applied to C++ by C++ers in saying that 99% of the time you don't need classes exposed as first class objects. For this reason, and many others, I prefer Smalltalk.
Yes, but, like the inspiration of genius, that remaining 1% is crucial. C++ give you no powerfull hooks. If you are lucky, your C++ will cough up the name of the class of an object in a non-portable fasion.]
Also, you seemed to have mistaken my perception of Smalltalk for an argument of why it should stay like it is. I really do wish people gave some *good* thought to the art of a Smalltalk meta-object protocol.
I'm pointing out that by adding OO "features" to Smalltalk, you give up a prime benifit of it's simplicity. Read again what I said about exceptions. They use powerful hooks like thisContext, and unwind-protection (in VW). The are part of the code base, like OrderedCollection.
However, I wish things like message sending, message handling, instance variable accessors, and messaging were more generalized and accessible. I hope that eventually Squeak will evolve far beyond ANSI Smalltalk.
I hope that ANSI Smalltalk will evolve, but I'm afraid I'm quite alone amongst Smalltalkers in that regard. Squeak, and all of the other Smalltalks are already far beyond ANSI. ANSI is merely an agreement upon the known.
For example, Smalltalk give you single static inheritence, but if you want to implement multiple or dynamic inheritence, you can.
But not easily.
Compared to what? Java? C++? Fortran? Sure, it's probably easier to do in Self than Smalltalk. Scheme... tough to say.
Likewise for multi-polymorphism (although I'm sure we can do better than double-dispatching & coersion). You can be a productive Smalltalk programmer, and never even know about primitive methods.
Of course, and that's a (or should be) key design goal.
Sure. Primitive methods and the prime anomoly are rites of passage for Smalltalkers.
There was a good mind-bending paper at OOPSLA a decade or so ago, on how to add back-tracking to Smalltalk without VM support (using thisContext).
I'm afraid that if we add stuff like this to Smalltalk, it will turn into CLOS.
In my opinion thisContext is a key concept and we should not strive to hide it's presence. Also, implementing a return with ^ seems non-smalltalky to me. It seems cleaner and more consistent to say "thisContext terminateAndAnswer: someObject" (although it is obviously more cumbersome to type). The more expressive form clearly indicates exactly what is happening.
It's not hidden. Its just a power tool thats not for everyday use.
I dont what to see code like:
| tempVar | thisContext tempAt: 1 put: 'Initial Value'
I want:
| tempVar | tempVar := 'Initial Value'
You may find it insightful to browse references to: #tempAt: and #tempAt:put:
Similarly, Bad:
gun perform: #shoot.
Good:
gun shoot.
Obfuscatory:
gun perform: #perform:with: with: #shoot
I usually introduce programmers to Smalltalk by saying:
"Smalltalk is a very simple language. There's only three things you can do: Assign a variable, Return a value, and send a message.
This is obviously a gross simplification, but since everybody knows about what the first 2 things do, this puts the focus upon *messaging*, the soul of Smalltalk.
Not objects. Not Classes. Not inheritence.
And, InstructionStreams are really the fundamental unit of processing and should take much of the responsibility currently held in Process. Especially when considering how one would architect a Squeak that takes advantage of multi-processor CPUs.
I'm personally more concerned with language design, not implementation. But, fundamentatly, there's got to be that eval/apply gem somewhere. As far as InstructionStreams being fundamental... I'm against byte-code standardization. It only solves political problems.
(of course most of Smalltalk's problems are political (compared to Java, for example) not technical, but that's a whoooole other thread) (Do Smalltalker's *really* want Smalltalk to be more popular? In any revolution there are 2 sides.... the establishment, and the movement)
I say we build stuff like this around the powerful hooks... much the way Exceptions are built around thisContext. Smalltalk was never about quiet syntax. Smalltalk is about deeper semantics.
self doStuff. ^ vs. self doStuff. Processor terminateActive.
I certainly don't want a quiet syntax for killing a process! I want to HEAR the BANG of the bullet that kills it!
I didn't mean to imply that "thisContext terminate" should terminate the Process (as it does), but rather that it should complete processing of a method context (as "^self" does).
- Stephen
Squeak kinda has this:
thisContext return: 'The Answer' to: thisContext home sender
But it is so far from working that it's funny. The OOPSLA paper shows how to make it work.
Before I close this lengthly response, let me point out that the above questions I asked are not rhetorical. I really want to know what all of you out there think.
If I were to pick one existing OO feature that I would be interested in exploring in Smalltalk, it would be method combination (maybe mixed with mult-methods)
-- Mike Klein
squeak-dev@lists.squeakfoundation.org