"Andrew C. Greenberg" wrote:
> 
> By the way, good messaging code makes for lousy function-based
> programming, stylistically speaking -- if you think in terms of
> functions, there's lots of global state being thrown around,

Global state? I don't see much global state. Message sends (by any name)
just pass values forth and back. These objects may be large, but they
are not global: you can always create a second instance.

> many
> side effects without express naming of them in the function
> specification,

As long as the side effects are limited to the objects involved as
parameters passed or results returned or being the message recipient,
this is as side-effect-free as one can get when doing real work. Of
course, the objects may be large, but that is not a problem in itself.

Well, a method should name which of its parameters it modifies (in an
abstract sense: it is OK if some object just does some caching or
otherwise not externally visible things).

> and of course, the problem that every Squeak
> "function" is and can be a coroutine.

This is new to me. How this?

> It is interesting that I found myself re-reading the Blue Book a few
> weeks ago, not so much because it is a useful reference book once you
> are "up and going," but because I found it helpful to read it again
> from a "Smalltalker's" eyes.  Indeed, in my first readings about
> fifteen years ago, I was thinking as Joachim suggests, and even in my
> recent re-readings when I first got Squeak late last year, I
> initially thought in much the same way.  But now, things have changed
> indeed -- and I am a better coder (in Smalltalk) for it.

You seem to have undergone a mental shift lately, so you may be able to
explain it to somebody who obviously hasn't lately. Please do!

Regards,
Joachim
-- 
Please don't send unsolicited ads.