From: johnzabroski on
On Mar 5, 10:09 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
wrote:
> On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote:
> > raould <rao...(a)gmail.com> wrote:
> >> On Mar 4, 1:21 am, Nilone <rea...(a)gmail.com> wrote:
>
> >>> > * the old hierarchical breakdown of procedures in structured
> >>> > programming vs. the peer relationship that should be used in oo. i
> >>> > don't even know how to visualize these, it would be great to see a
> >>> > small toy code example of the difference.
>
> >>> The theoretical models will help you visualize.  I don't know what
> >>> code example would illustrate the issues well.  Post something you're
> >>> familiar with, and we can discuss and criticize possible designs.
> >>> Distrust animal and vehicle based examples.
>
> >> unfortunately i'm so not understanding the topic yet that i don't even
> >> have an example i could post. by visualize i meant have an example of
> >> it i can work through in my head. like, i can work through an example
> >> of single dispatch java vs. multiple dispatch in my head since i've
> >> written that code enough times.
>
> >> my vague sense of it so far comes from reading Lahman's blog, that it
> >> is in particular about control-flow, rather than about, say, type
> >> hierarchy. which i can in some ways i think i understand (like, many
> >> conditional tests can be re-coded into the object hierarchy, to
> >> replace the conditional with polymorphism) but i suspect i'm not fully
> >> groking it.
>
> > Here is a simple quote that might help. "In OO programs, objects tend to
> > tell other objects what happened, instead of telling them what to do."
>
> Well, I see no difference if action is a simple function of state. To tell
> the object "do X" is same as to tell it "we are in the state, where you
> will do X." There could be a difference in an asynchronous system, or when
> participants had some intelligence making their own decisions in same
> states, but neither is typical to a well-designed OO program. The design
> principles are rather opposite:
>
> 1. Make it deterministic and testable
> 2. Keep objects behaviour simple
>
> etc.
>
> > If you want to visualize how objects in a good OO program work, study
> > how ants in a colony work together to get things done. Contrary to
> > popular opinion, the Queen does not tell each ant what it should do...
>
> It would be a very bad idea to design a program as an ant colony:
>
> 1. Ants designed same (worker, fighter, queen), objects are not
> 2. They act stochastically, programs are desired to be predictable
> 3. They are wasting a huge amount of resources (computational and time)
> 4. They communicate in an extremely inefficient, slow and unreliable way
> 5. They lack memory and any ability to learn
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

1. Clearly you did not understand the presentation
2. Petri nets are inherently non-deterministic.
3. With respect to what? Have you seen the studis done on performance
of Complex Adaptive Systems based on ant colony studies? Look at the
Anthill Project in Java.
4. Handshaking does impose an overhead for fine-grained communication,
but for coarse-grained communiucation, synchronous designs turn out to
be more complex
5. Lacking memory is a FEATURE of finite state automata. Determining
the next state in the system only depends on the current state and
next transition. It is more MODULAR. The "ability to learn" is
actually dependent on how you think of learning; the way ant's stack
dead ant bodies requires no learning, yet exhibits artificial
intelligence! It is coordination without explicit communication; an
object-oriented Mediator pattern.
From: johnzabroski on
On Mar 5, 2:19 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
wrote:
> On Fri, 05 Mar 2010 18:13:44 +0000, S Perryman wrote:
> > Dmitry A. Kazakov wrote:
>
> >> On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote:
>
> >>>If you want to visualize how objects in a good OO program work, study
> >>>how ants in a colony work together to get things done. Contrary to
> >>>popular opinion, the Queen does not tell each ant what it should do...
>
> >> It would be a very bad idea to design a program as an ant colony:
>
> >> 1. Ants designed same (worker, fighter, queen), objects are not
> >> 2. They act stochastically, programs are desired to be predictable
> >> 3. They are wasting a huge amount of resources (computational and time)
> >> 4. They communicate in an extremely inefficient, slow and unreliable way
> >> 5. They lack memory and any ability to learn
>
> > Social insect colonies are event-driven.
>
> > There are "broadcast" event channels communicated via pheromones.
> > For example :
>
> > - the signal that a queen exists
> > - the signal that the colony is being attacked
>
> > Social insect colonies are also procedural.
> > Maintenance of the colony structure, tending to the queen etc.
>
> > Both aspects are exhibited in good OO programs.
>
> Broadcasting is asynchronous 1-n messaging. OOPL rather deploy peer-to-peer
> synchronous messaging. The vital advantage of 1-1 synchronous messages
> (calls) are:
>
> 1. you can pass individual parameters. (Ant messages lack parameters
> altogether);

If these individual parameters are 'guards', then it is not much of a
feature.

Anyway, the real design issue with Methods and Parameters are really
about encoding messages with multi-valued attributes.

> 2. you can have results, this is a key feature that enables programming
> free of side effects;

Purity guarantees programs are free of side effects. Purity is also
not *directly* that interesting for many problems, e.g. interactive
model of computation such as Persistent Turing Machines and Evolving
Algebras (Abstract State Machines).

> 3. you don't have to worry about race conditions;

You still have to worry about race conditions, deadlocks, and ABA
problems.

These problems have to do with *ordering* side-effects. Even in
Haskell, with monads, you can have these problems.

> 4. objects can be passive, so you can have small things objects, like
> numeric ones, which otherwise could not be objects. (there would be too
> many of them);

Objects are a form of data abstraction that allow for procedural
abstraction. I think by "passive" you mean exposing implementation
details and breaking encapsulation. Yes, objects can do that, because
objects control their own representation. This has advantages and
disadvantages.

> 5. you have a uniform structure, where there is no dedicated
> parameter/result, like message receiver, but all parameters and results can
> be considered objects and treated equally;

I don't understand what you are saying, and you will have to rephrase.

> 6. you can do static analysis and other nice things much easier.

Ease of static analysis has to do with properties other than just
"objects", and the reason most object-oriented languages are difficult
to statically analyze are legion, but you are (dangerously)
oversimplifying things.

> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

From: johnzabroski on
On Mar 5, 7:18 pm, "johnzabro...(a)gmail.com" <johnzabro...(a)gmail.com>
wrote:
> On Mar 5, 2:19 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
> wrote:
>
>
>
> > On Fri, 05 Mar 2010 18:13:44 +0000, S Perryman wrote:
> > > Dmitry A. Kazakov wrote:
>
> > >> On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote:
>
> > >>>If you want to visualize how objects in a good OO program work, study
> > >>>how ants in a colony work together to get things done. Contrary to
> > >>>popular opinion, the Queen does not tell each ant what it should do....
>
> > >> It would be a very bad idea to design a program as an ant colony:
>
> > >> 1. Ants designed same (worker, fighter, queen), objects are not
> > >> 2. They act stochastically, programs are desired to be predictable
> > >> 3. They are wasting a huge amount of resources (computational and time)
> > >> 4. They communicate in an extremely inefficient, slow and unreliable way
> > >> 5. They lack memory and any ability to learn
>
> > > Social insect colonies are event-driven.
>
> > > There are "broadcast" event channels communicated via pheromones.
> > > For example :
>
> > > - the signal that a queen exists
> > > - the signal that the colony is being attacked
>
> > > Social insect colonies are also procedural.
> > > Maintenance of the colony structure, tending to the queen etc.
>
> > > Both aspects are exhibited in good OO programs.
>
> > Broadcasting is asynchronous 1-n messaging. OOPL rather deploy peer-to-peer
> > synchronous messaging. The vital advantage of 1-1 synchronous messages
> > (calls) are:
>
> > 1. you can pass individual parameters. (Ant messages lack parameters
> > altogether);
>
> If these individual parameters are 'guards', then it is not much of a
> feature.
>
> Anyway, the real design issue with Methods and Parameters are really
> about encoding messages with multi-valued attributes.

Just to clarify:

What I meant here is that objects are fundamentally higher-order, so
the issue of needing lots and lots of parameters really never comes up
in the design of programs.

Moreover, if I see code that interprets a message based on its
parameters, rather than the message itself, I think about whether or
not that should be refactored, as it seems like a code smell. The key
idea is that it suggests to me a weakly encapsulated service, because
the receiving object must understand additional semantics about
parameters in order to understand the contents of a message. This is
likely to be a violation of the Law of Demeter, and in general the use
of guards will be *the* source of *architectural* decay in OO systems.

Functional languages, using algebraic data types, have things a little
easier in terms of *reasoning about* this *architectural* decay,
because they can append operations easily to the data type. However,
they are still introducing the decay by requiring filling in the
bubbles to have an operation that is *total* or at least *partial* and
gives a *bottom* value. This sort of way of writing programs lends
itself well to thinking about programs by encoding logic in terms of
pattern matching.
From: Dmitry A. Kazakov on
On Fri, 5 Mar 2010 16:18:29 -0800 (PST), johnzabroski(a)gmail.com wrote:

> On Mar 5, 2:19�pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
> wrote:
>> On Fri, 05 Mar 2010 18:13:44 +0000, S Perryman wrote:
>>> Dmitry A. Kazakov wrote:
>>
>>>> On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote:
>>
>>>>>If you want to visualize how objects in a good OO program work, study
>>>>>how ants in a colony work together to get things done. Contrary to
>>>>>popular opinion, the Queen does not tell each ant what it should do...
>>
>>>> It would be a very bad idea to design a program as an ant colony:
>>
>>>> 1. Ants designed same (worker, fighter, queen), objects are not
>>>> 2. They act stochastically, programs are desired to be predictable
>>>> 3. They are wasting a huge amount of resources (computational and time)
>>>> 4. They communicate in an extremely inefficient, slow and unreliable way
>>>> 5. They lack memory and any ability to learn
>>
>>> Social insect colonies are event-driven.
>>
>>> There are "broadcast" event channels communicated via pheromones.
>>> For example :
>>
>>> - the signal that a queen exists
>>> - the signal that the colony is being attacked
>>
>>> Social insect colonies are also procedural.
>>> Maintenance of the colony structure, tending to the queen etc.
>>
>>> Both aspects are exhibited in good OO programs.
>>
>> Broadcasting is asynchronous 1-n messaging. OOPL rather deploy peer-to-peer
>> synchronous messaging. The vital advantage of 1-1 synchronous messages
>> (calls) are:
>>
>> 1. you can pass individual parameters. (Ant messages lack parameters
>> altogether);
>
> If these individual parameters are 'guards', then it is not much of a
> feature.

Hmm, guards and barriers are not parameters.

What I mean is that you can pass 123 to the object X and 321 to the object
Y. This is impossible when broadcasting messaging is used, unless the
broadcaster knew its subscribers and puts object ID into messages, which in
effect would be no broadcasting anymore, but an awkwardly implemented
peer-to-peer communication. Ants messages are even worse, they do not have
parameters at all, except, maybe, spatial coordinates, e.g. when ants place
pheromone marks on the path.

> Anyway, the real design issue with Methods and Parameters are really
> about encoding messages with multi-valued attributes.

Huh, what is the problem with encoding? That looks a low-level
implementation detail to me. Not a design issue at all.

>> 2. you can have results, this is a key feature that enables programming
>> free of side effects;
>
> Purity guarantees programs are free of side effects.

Receiver of a broadcast message cannot be pure.

>> 3. you don't have to worry about race conditions;
>
> You still have to worry about race conditions, deadlocks, and ABA
> problems.

When caller and the callee are synchronous you don't.

> These problems have to do with *ordering* side-effects.

Yes, see the point 2. More side-effects get exposed and limited to the
arguments and the results, easier it becomes to control the ordering of.

>> 4. objects can be passive, so you can have small things objects, like
>> numeric ones, which otherwise could not be objects. (there would be too
>> many of them);
>
> Objects are a form of data abstraction that allow for procedural
> abstraction. I think by "passive" you mean exposing implementation
> details and breaking encapsulation.

Under "passive" I mean objects, which do not encapsulate a scheduling item,
like a thread. This does not expose implementation details, so long the
contract of the object's type does not explicitly state anything about
activity. But the point is that peer-to-peer communication enables passive
implementations, e.g. an integer variable can be an object. You certainly
could implement arithmetic on the basis of an ant colony (I even remotely
remember some reports about bees (as a colony) capable to count), but that
would be an abomination to do.

>> 5. you have a uniform structure, where there is no dedicated
>> parameter/result, like message receiver, but all parameters and results can
>> be considered objects and treated equally;
>
> I don't understand what you are saying, and you will have to rephrase.

A message is sent to a receiver object. This is an asymmetric scheme. The
parameters and the results of the message are treated differently from the
receiver object. Usually it is also reflected by the syntactic:

Mouse.Take (Cheese)

A symmetric scheme is:

Take (Mouse, Cheese)

This is far more powerful and general. Methods are no more object's
members, but defined on tuples of objects. Multiple dispatch supersedes
single dispatch etc.

>> 6. you can do static analysis and other nice things much easier.
>
> Ease of static analysis has to do with properties other than just
> "objects", and the reason most object-oriented languages are difficult
> to statically analyze are legion, but you are (dangerously)
> oversimplifying things.

OK, let's state it so. Static analysis is easier to do for synchronous
communications and passive objects.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on
On Fri, 5 Mar 2010 16:03:55 -0800 (PST), johnzabroski(a)gmail.com wrote:

> On Mar 5, 10:09�am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
> wrote:
>> On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote:
>>> raould <rao...(a)gmail.com> wrote:
>>>> On Mar 4, 1:21�am, Nilone <rea...(a)gmail.com> wrote:
>>
>>>>> > * the old hierarchical breakdown of procedures in structured
>>>>> > programming vs. the peer relationship that should be used in oo. i
>>>>> > don't even know how to visualize these, it would be great to see a
>>>>> > small toy code example of the difference.
>>
>>>>> The theoretical models will help you visualize. �I don't know what
>>>>> code example would illustrate the issues well. �Post something you're
>>>>> familiar with, and we can discuss and criticize possible designs.
>>>>> Distrust animal and vehicle based examples.
>>
>>>> unfortunately i'm so not understanding the topic yet that i don't even
>>>> have an example i could post. by visualize i meant have an example of
>>>> it i can work through in my head. like, i can work through an example
>>>> of single dispatch java vs. multiple dispatch in my head since i've
>>>> written that code enough times.
>>
>>>> my vague sense of it so far comes from reading Lahman's blog, that it
>>>> is in particular about control-flow, rather than about, say, type
>>>> hierarchy. which i can in some ways i think i understand (like, many
>>>> conditional tests can be re-coded into the object hierarchy, to
>>>> replace the conditional with polymorphism) but i suspect i'm not fully
>>>> groking it.
>>
>>> Here is a simple quote that might help. "In OO programs, objects tend to
>>> tell other objects what happened, instead of telling them what to do."
>>
>> Well, I see no difference if action is a simple function of state. To tell
>> the object "do X" is same as to tell it "we are in the state, where you
>> will do X." There could be a difference in an asynchronous system, or when
>> participants had some intelligence making their own decisions in same
>> states, but neither is typical to a well-designed OO program. The design
>> principles are rather opposite:
>>
>> 1. Make it deterministic and testable
>> 2. Keep objects behaviour simple
>>
>> etc.
>>
>>> If you want to visualize how objects in a good OO program work, study
>>> how ants in a colony work together to get things done. Contrary to
>>> popular opinion, the Queen does not tell each ant what it should do...
>>
>> It would be a very bad idea to design a program as an ant colony:
>>
>> 1. Ants designed same (worker, fighter, queen), objects are not
>> 2. They act stochastically, programs are desired to be predictable
>> 3. They are wasting a huge amount of resources (computational and time)
>> 4. They communicate in an extremely inefficient, slow and unreliable way
>> 5. They lack memory and any ability to learn
>>
>> --
>> Regards,
>> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
>
> 1. Clearly you did not understand the presentation

I am not a biologists, I am a programmer, I know what I am doing... (:-)).

> 2. Petri nets are inherently non-deterministic.

So? It does not mean that we program using them. We do using OOPL.

> 3. With respect to what? Have you seen the studis done on performance
> of Complex Adaptive Systems based on ant colony studies? Look at the
> Anthill Project in Java.

My first education is AI (pattern recognition, machine learning,
uncertainty model, that awful stuff, you know). I do *not* buy swarm
intelligence, agents, genetic algorithms etc. It is a snake oil, sorry
don't want to offend anybody.

> 4. Handshaking does impose an overhead for fine-grained communication,
> but for coarse-grained communiucation, synchronous designs turn out to
> be more complex

That requires a proof.

In any way if we had estimated how much data are sent over the messaging
system of an ant colony, the response times of the colony etc, we would get
quite disappointing figures. We, human programmers, make our communication
systems much better.

> 5. Lacking memory is a FEATURE of finite state automata.

Firstly FSA is a model. Secondly running FSA has memory (that is its
current state). Thirdly you can build (model) traditional memory using FSA.

> Determining
> the next state in the system only depends on the current state and
> next transition. It is more MODULAR.

Sorry, did you ever used a state machine to program anything of real-life
size? I did. It is not modular, it is an utter mess, it is almost
unmaintainable. I avoid state machines even in the areas where they are
traditionally strong, like parsing.

> The "ability to learn" is
> actually dependent on how you think of learning; the way ant's stack
> dead ant bodies requires no learning, yet exhibits artificial
> intelligence!

OK, AI is usually addressed to the problems we have no idea how to solve.
Once a reliable solution is found the problem is no more counted as AI.
Yes, we presently cannot build an adequate computer model of insect's
behavior, so anything an ant does is an AI to us.

> It is coordination without explicit communication; an
> object-oriented Mediator pattern.

If communication can be hidden as an implementation detail, that is only
welcome. But this does not apply to ants, they communicate very explicitly.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de