![[prev]](../../icons/DocsLeftArrow.gif){kind=icon}
![[up]](../../icons/DocsUpArrow.gif){kind=icon}
![[next]](../../icons/DocsRightArrow.gif){kind=icon}
Some humorous articles and opinions I found in comp.lang.smalltalk and/or mailing lists.
Some seem stupid at first sight, but contain a deeper meaning on second thought...
I do certainly appreciate the philosophy behind these articles and definitely do not consider
them as stupid.
Read and enjoy - Claus.
To: squeak@cs.uiuc.edu Subject: Aha! How to get rid of Blocks in Smalltalk. From: David Farber <dfarber@numenor.com> Date: Wed, 19 Apr 2000 23:31:51 -0600 First of all, let me apologize if what I am about to propose is not a novel idea. I've certainly never heard anyone propose anything like it. Second, I must confess that this idea came to me while I was under the influence. The substance in question was Jef Raskin's excellent new book, "The Humane Interface". I strongly recommend that anyone on the list that has not bought and read this book do so ASAP. Now, to the heart of the matter: I have realized how Blocks can be removed as a language construct in Smalltalk without giving up functionality or power of expression. Why remove Blocks? Blocks have long been one of my biggest qualms with Smalltalk (perhaps second only to the lack of namespaces). I am sure that my original uneasiness came from having to get used to the wierd flow control contructs. But even once I was used to 'aBoolean ifTrue: [] ifFalse: []' and thought it was so cool that flow control could be left out of the base language and created, on demand, from simple message passing, I was still not entirely convinced that Blocks were The Right Thing To Do. Then, last night, in less than an hour after I had just finished Raskin's new book it hit me: Blocks are almost always unique functional units by virtue of grouping message sends. But Smalltalk already has a mechanism for creating new functional units by grouping message sends; it is called a Method. Having two ways to do the same thing violates the principle of monotony. As soon as my beef with Blocks was expressed in these terms, I knew for certain that 1) Blocks had to go and 2) they could be replaced with regular methods and message sends and not be missed. To put what I've just said into a (kind of) concrete example, what I am proposing is the following: WITH BLOCKS aCollection do: [ :each | a foo. b bar. self doSomethingWith: a with: b with: each]. WITHOUT BLOCKS newMessage := MessageSend send: 'doThisWith:with:with:' to: self with: #(a b). aCollection do: newMessage. METHOD doThisWith: a with: b with: c a foo. b bar. self doSomethingWith: a with: b with: c. (NOTE: To obviate the need for the Collection do: method to be rewritten, MessageSend would implement value: by just appending the object passed to the arguments array. I made up the MessageSend class just to make my point as cleanly as possible. The method send:to:with:super: in ContextPart actually does what I am describing.) To try and explain my idea one more time, all I have done is: 1) put the message sends formly grouped in the Block into their own method. 2) Explicitly created a message send. 3) Passed the message send instead of the Block. I don't see anything that cannot be done with this scheme that can be done with blocks. The advantage is that the language is now simpler, having removed a construct that, in the final analysis, didn't really contribute anything. Now, having to always explicitly create the message send as I did in the example above could lead to some serious brain damage; it is really quite cumbersome. So, what we need is a shorthand for creating explicit message sends just as #() is shorthand for Array creation. I don't have any definite ideas here, but one possiblity would be to re-use the old block semantics. [ :arg3 | receiver message: arg1 with: arg2 with: arg3] The example given above would now look like: aCollection do: [ :each | self doThisWith: a with: b with: each]. The above is an explicit message send, NOT a block. You could not, for instance, try to stuff a second message send in there or chain message sends with ;. That would be creating a new message grouping and that is what methods are for. The advantage here is that the new language specification is a proper subset of the old; you could file this into any current Smalltalk implementation and it would run. It should also be fairly straightforward to translate from the old to the new. The biggest drawback that I can see to this is that users who were presented with the change but not the rationale would probably not think to make a new method to take the place of the message grouping that would have been put inside the block. Well, I hope I have explained my idea clearly enough. Let me know what you think. I, for one, am estatic; I've finally figured out why I've always been uncomfortable with blocks and how I can get rid of them! At least, until someone bursts my bubble. :) david -- David Farber dfarber@numenor.com
To: squeak@cs.uiuc.edu
Subject: Aha! How to get rid of Objects in Smalltalk. (was RE: Aha! How to get rid of Blocks in Smalltalk)
From: "Vassili Bykov" <vassili@objectpeople.com>
Date: Thu, 20 Apr 2000 11:55:44 -0400
First of all, let me apologize if what I am about to propose sounds
sarcastic with respect to an earlier post on this list. I am not making
evil fun of David's post. (Yes, so far I AM serious).
Second, I must confess that this idea came to me while I was under the
influence of the recent events at the company I work for. The substance in
question is described on our excellent webpage "www.objectpeople.com". I do
NOT strongly recommend that anyone reads it, unless you want to know why I
wanted to lighten up.
Now, to the heart of the matter: I have realized how Objects can be removed
as a language construct in Smalltalk without giving up functionality or
power of expression.
Why remove Objects? Objects have long been one of my biggest qualms with
Smalltalk (perhaps second only to the lack of continuations). I am sure that
my original uneasiness came from having to get used to the weird variable
binding and method lookup constructs. But even once I was used to 'Object
subclass: #MyClass instanceVariableNames: '...' ...' and thought it was so
cool that methods could me invoked, on demand, by simply sending messages, I
was still not entirely convinced that Objects were The Right Thing To Do.
Then, last night, in less than an hour after we had just finished a staff
meeting it hit me: Objects are almost always unique structural units by
virtue of grouping variable bindings and methods. But Smalltalk already has
a mechanism for creating new structural units by grouping variable bindings;
it is called a BlockClosure. Having two ways to do the same thing violates
the principle of monotony. As soon as my beef with Objects was expressed in
these terms, I knew for certain that 1) Objects had to go and 2) they could
be replaced with regular block closures and block closure invocations and
not be missed.
To put what I've just said into a (kind of) concrete example, what I am
proposing is the following:
WITH OBJECTS
Object subclass: #Car
instanceVariableNames: 'speed'
classVariableNames: ''
poolDictionaries: '' !
! Car methods !
speed
^speed !
speed: aNumber
speed := aNumber !
stop
speed := 0 ! !
WITHOUT OBJECTS
Car := [ | speed |
speed := 0.
[:message |
#speed == message
ifTrue: [[speed]]
ifFalse: [#speed: == message
ifTrue: [[:newSpeed | speed := newSpeed]]
ifFalse: [#stop == message
ifTrue: [[speed := 0]]
ifFalse: [self error: 'MessageNotUnderstood', message]]]]]
CREATING AN INSTANCE
aCar := Car value.
SENDING MESSAGES
(aCar value: #speed:) value: 65. "aCar speed: 65"
(aCar value: #speed) value. "aCar speed"
(aCar value: #stop) value. "aCar stop"
To try and explain my idea one more time, all I have done is: 1) put the
methods formerly grouped in the Object into their own closures. 2) Explicitly
implemented closure look-up. 3) Invoked a closure instead of sending a
message.
I don't see anything that cannot be done with this scheme that can be done
with objects. The advantage is that the language is now simpler, having
removed a construct that, in the final analysis, didn't really contribute
anything. The biggest drawback that I can see to this is that users who
were presented with the change but not the rationale would probably not
think to make a new closure to take the place of the method grouping that
would have been put inside the class.
Well, I hope I have explained my idea clearly enough. Let me know what you
think. I, for one, am estatic; I've finally figured out why I've always
been uncomfortable with objects and how I can get rid of them! At least,
until someone bursts my bubble. :)
--Vassili
Vassili Bykov
BEA Systems, Inc.
These two articles show us the duality of objects and closures - they can be mapped onto each other and simulated/implemented with each other. Read SICP (Structure and Interpretation of Computer Programs) for a very good introduction to all of this.
--Claus Gittinger
Many moons later, the student returns,
"Master, you were right, objects are more powerful than closures,"
to which the master replied,
"You fool, closures are more powerful than objects".