Fear and loathing of the "perification" of Smalltalk

Peter William Lount peter at smalltalk.org
Sat Sep 15 00:01:18 UTC 2007


Alan Kay wrote:
> I first saw this in EULER (Wirth and Weber ca 1966), but then saw an 
> earlier similar notion by Landin in ISWIM and its predessors. I used 
> the idea in my first OOP language (FLEX ca 1967-9), which also had 
> complete static nesting of scopes, etc.
>
> But later I decided I didn't like blocks as values because they are 
> super time bombs when passed around and completely violate 
> encapsulation. I really wanted external objects (not internal blocks) 
> to be passed around, and wanted a simpler way to think of contexts 
> internally. So we left them out of the first few Smalltalks. (I still 
> don't like them ...)
>
> Cheers,
>
> Alan 

Hi Alan,

That's an interesting history lineage. Thank you.

Are you saying that those systems had blocks and methods with the same 
syntax?

I suppose you'd have to add Lisp to that list since Lisp functions and 
Lisp lambda's are pretty much the same thing, lists.

You've mentioned that you don't like Blocks before. I've never 
understood why. Certainly they do violate encapsulation since they can 
be passed around and who knows where they'll end up (or even what they 
do when you get one).

Is it that you don't like the use of the levels of nesting in the syntax 
provide by "[" and "]" that mark the block of code? What would replace 
them? Is it even possible for a linear one dimensional text grammar to 
do that I wonder?

I'm glad that you added Blocks to Smalltalk-80 since they enable an 
amazingly huge domain of extensibility of the language flow control 
structures. That makes them worthwhile.

It does seem that you were aiming at something else though. Have you 
written about that? What are your thoughts on what you're aiming for?

I often find myself arguing for the creating of objects rather than 
using blocks (and collections and dictionaries) in many professional 
situations. People who get blocks sometimes rely on them way too much 
and it obfuscates the code - anyone can write spaghetti code. As soon as 
you are trying to do more than one different thing in a block or have 
more than one data/object value to manage it's often better for an 
object instead of a block. Often methods would be better off as their 
own independent objects for similar reasons.

A nice aspect of Blocks is that they are extensible and that they have a 
very easy protocol, #value, #value:, etc... for working with them. 
Objects can even take on the block protocol at times pretending to be a 
Block by implmementing value. That's how my SortCriteria (aka  Sort 
Critter) objects work within SortedCollections 
(http://www.smalltalk.org/components/SortCriteria.html).

All the best,

Peter










More information about the Squeak-dev mailing list