"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
squeak-dev@lists.squeakfoundation.org