Mark -- I'd be happy to elaborate. maybe in doing so I can state my
position more clearly.

Raskin does not talk about blocks in his book; the book is about interface
design. Towards the end of the book he does touch briefly on programming
languages and environments, but the bulk of the book is dedicated to
exploring why computers are so hard and frustrating to use and what can be
done about it. In the process of doing so, he talks about Monotony.

In chapter three ("Meanings, Modes, Monotony and Myths") he says this about
monotony:

  "I use the term monotonous, tongue partially in cheek, to describe an
interface having only one way to accomplish a task...The more monotony an
interface has for a given task space, the easier it is for the user to
develop automaticity, which, after all, is fostered by not having to make
decisions about what method to use."

He has a lot more say; all of it worth reading. The link to his book and my
idea is that the idea presented itself to me (i certainly was not
consciously thinking about blocks at the time) in exactly these words:
"blocks violate monotony".

to elaborate, what this means is that both methods and blocks function as
mechanisms for grouping messages. the principle of monotony says that there
should only be one way in the system to do any one thing. either blocks or
methods need to go.

so, you may be thinking, "Big deal. Who cares that there are blocks and
methods and that they can both group messages?" The reply is, if there are
two ways to group messages, which way should you use? Are the two exactly
equivalent? If not, what happens when you choose one but later on find out
that you should have chosen the other?

an excellent example of this happened on a 3 year Smalltalk project that i
was on a few years ago. as part of the project, we built our own GUI
framework from scratch. in the framework, you could attach a block to each
UI element that would get executed whenever you activated that element
(e.g. you clicked on a button). at the time, we didn't think twice about
the design, but later we lived to regret the decision.

there were several ramifications to our design; all of them bad. one of the
really amazing things about developing in Smalltalk was that each day when
we came into work, we fired up our application and the application ran all
day long as we coded and hacked on it. no starting and stopping the
application. no program compiling. just change a method, try out the
section of the application involved, handle any debug windows that popped
up, and then move on. but, as soon as we introduced these UI action blocks,
we suddenly lost this flexibility. if code in a block was wrong, we had to
stop and restart the application. we could also not modify or extend blocks
by subclassing. those little snippets of code in those blocks (and they
grew as the system grew) were essentially lost to us.

well, one could always just lay the blame on us for being stupid
programmers; after all, i think one of Kent Becks's Smalltalk Best
Practices is not to use blocks for delayed code execution (in our defense,
Kent's book wasn't out at that time). but if we were to refrain from such a
thought and ask instead if, perhaps, the language might share some of the
blame, then maybe we could make an adjustment to the language for the better.

so back to the thought that ambushed me earlier this week. after further
thought on the matter, "blocks violate monotony" doesn't quite address the
issue directly. it is more accurate to say that part of the functionality
of blocks, the part that allows messages to be grouped together, violates
monotony. after all, blocks do more than just group messages. they also
create a message send that can be handled like any other object: passed
around, stored, sent messages to. hey, that's pretty powerful stuff;
definitely not something we want to throw away.

so try this out as a thought exercise. imagine blocks, as they are in
Smalltalk today, with the exception that the block can only contain one
message. if you wanted more than one message send in that block, you would
need to write a method on some object that contained those messages and
then call that method as your one message send in the block.

the first thing to note is that we really don't have blocks anymore. this
new thing isn't a block (i.e. block of code). it is (and i am not really
sure what the best terminology here would be) a reified activation context.
it is a MessageSend. a piece of the underlying language that can,
nonetheless, be manipulated like all the other objects in the system.

the second thing to notice is that now a programmer can't make a mistake
like the one we made with our UI blocks.

now we just have to satisfy ourselves that in snipping that one piece of
functionality from blocks we didn't take away any other piece of
functionality from blocks. as long as we didn't, we know that the system is
no less powerful for the change.

right now, i can't "prove" that constraining blocks to only one message
send doesn't adversely affect the remaining functionality of a block. in
particular, non-local returns might be axed. this would be a very suprising
result to me (but maybe not suprising to others; i just have never
scrutinized non-local returns before).

if this were the case, it would only reinforce my point: how is a
programmer supposed to know when a particular grouping of message sends
will need to take advantage of a non-local return? what if this need
oscillates over time? how is a programmer supposed to learn these things?
here i've been coding in Smalltalk for over eight years, and i'm only just
now able to articulate a functional difference between methods and blocks
and thus able to consciously take that difference into account when coding.

at least i feel like i am out in front of the problem now. even if blocks
can't simply be changed to allow only one message send, i can say (to
myself and to others) "watch out! blocks violate monotony". :)

david


At 11:05 AM 4/20/00 -0400, you wrote:
>>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.
>
>David, could you say something about why Raskin's book made you think 
>of removing blocks from Smalltalk?  Does Raskin address blocks or 
>something similar?
>
>Thank you!
>   Mark
>
>--------------------------
>Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
>(404) 894-5618 : Fax (404) 894-0673 : guzdial at cc.gatech.edu
>http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
>
>
--
David Farber
dfarber at numenor.com