agree at carltonfields.com wrote:
> 
> > "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.
> 
> Well, for starters, the class and metaclass structure, the structure
> and existence of which is presumed in Joachim's model of messaging as
> procedures, is a global state.

Yes. As is the class structure in any OO language. Or with available
funtions and modules in any programming language, OO or not.
There's no problem with large global state as long as that state is
immutable. Given that most Smalltalk code doesn't modify the class
structure at run-time, I don't see a problem here. I hope it is
consensus here that creating or destroying a class or method at run-time
is a dangerous operation that application code should with proper care
if at all!

> And with respect, the "big object" dodge distinctly distinguishes
                                       :((
> modern procedural programming methodologies, where the very point
> of a parameter list is *narrow* the state that is being considered.

An interface can still be very narrow even if the passed objects are
huge. This is not a dogde, this is the standard way of doing
abstractions.
The important point being, of course, that the callee doesn't make use
of everything in the large parameter; it just uses a specific protocol
of what it's being passed.
Smalltalk doesn't have a formal way of specifying this, but I think the
Squeak methods limit themselves in exactly this fashion. I conclude this
from the fact that Squeak is working - it would have collapsed under the
sheer complexity and intricate interdependencies of that wide-interface
coding style :)

> Under Joachim's model, no multiple-parameter functions are needed at
> all, since all function calls can be modelled as a single-parameter
> call, passing just the "large object," call it "mobyMemory."

Sorry, this is grossly misrepresenting what I said. Please do me a favor
and don't select the most unreasonable interpretation of what I say just
to make a point.

> > 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.
> 
> This is mere wordplay.  An object that is taken to be a large "local
> state" is methodologically equivalent to using global function calls.
> Indeed, Joachim's argument can be applied to C as well to argue there
> can be no side-effects or global variables in a c-function.  After
> all, a C-function call is just a function call with an implied (albeit
> large) parameter to the global state.

Wrong. You cannot have two sets of global variables in C.

Globals are wrong for two reasons:
1) Because you cannot have two of them if you need them, so reusing the
code in a context where the globals become instances is often
impossible.
2) Because globals tend to be a very wide interface.

You keep talking about (2), I was addressing just (1). No wonder you're
finding deficiencies in my arguments :}

> > 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).
> 
> This, of course, points out a fundamental *pedagogical* difference
> between the method and the message.  The message doesn't care about
> (or even relate to) any underlying structure of the object -- it
> doesn't impliedly "name" the parameters it modifies.  The message
> 
>         aStream next
> 
> may or may not make a reference to a collection and point, to a file
> or to a seed for a random number generator.  Nor does every method
> called to implement a message for a particular class need to know
> everything there is to know about the local state to function, when
> it can define the operations by way of messaging.  It is the
> difference between focusing on the protocols and focusing on the
> implementation.

I don't understand what you're saying here.

> > > and of course, the problem that every Squeak
> > > "function" is and can be a coroutine.
> > > This is new to me. How this?
> 
> I wrote a pipe-and-filter implementation as an example in a recent
> colloquy with Marcel, all entirely in Squeak, and all without using
> any operating system calls.  Each filter is written precisely as
> though it completely runs through its input stream, along the lines
> of:
> 
>  inStream atEnd whileFalse: [ outStream nextPut: inStream next ]
> 
> Each filter cedes the machine when its streams aren't available as
> expected, and ultimately the filterStream (sorry Marcel :-) ) has the
> desired overall effect.  Sure, this can be coded in an operating
> system (which views processes as coroutines), but it is not
> "inherent" in each C program.

Yes, that's one way of how filters can work. However, how do you stop
the processing? If you're doing it with blocks, you're just using
closures: hardly an OO-specific technique.

> > 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!
> 
> I have been trying to do so.  :-)  Bear with me.

Indeed :)

>  Meanwhile, my suggestion is to defer to others, particularly guys
> like Alan, while you mess with it -- build something real, and build
> it again.  See how much less painful it is to "build one to throw
> away," as each refactoring gets better, simpler and more functional.
>  Eventually, you start discarding "old tricks," stop trying to
> "optimize" things you routinely considered a principal priority, and
> when the entire result actually runs better, faster and more cleanly
> than your other efforts, you'll see that "something" is "different."
> 
> If it was easy to articulate reasons for this, Smalltalk would not
> have been so fixed all these years in its status as a minority
> programming language.

Well, I have always being rather insistent on getting explanations why.
I keep getting on people's nerves with that habit, but it helped me gain
lots of interesting insights. Apologies if anybody finds this
irritating.

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