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
|