Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Brown, John Mickey]

From: Jeff Gonis mailto:jeff.go...@gmail.com>>
> >To: Alan Kay mailto:alan.n...@yahoo.com>>
> >Cc: Fundamentals of New Computing mailto:fonc@vpri.org>>
> >Sent: Tuesday, February 12, 2013 10:33 AM
> >Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> >
> >
> >I see no one has taken Alan's bait and asked the million dollar question: if 
> >you decided that messaging is no longer the right path for scaling, what 
> >approach are you currently using?


>From my last trip to the SPLASH conference a few years ago, I've been
contemplating a lot of these ideas. Especially the messaging paradigm and
the current conundrum with concurrency and scaling.
A common theme (brought up by Ivan Sutherland paraphrased here) is that in
the past processing was expensive, now its communication. From the sheer
amount of development code and processing done to pack up data in an
understandable form, serialize it, encrypt it, etc so it can get to
another component to process (at least at the macro distributed systems
level). Now it's a concern with the multi-core processors that need to
process data. I went to some of the workshops on the functional languages
and Actors as a way to handle some of these issues through asynchronous
messaging.

My thought, but I've not found much work in this area is in this era of
virtualization, a small program or service can be instantiated anywhere as
long as location independence is honored.
So why not do a lot of the "distributed work" by instantiating these
services to where a majority of the data is located. Sure there will be
times when it needs to be shipped somewhere, but most of the communication
needed would be smaller control data to coordinate the program
instantiations and handoff (Like some of the IPC work I used to do with
unix processes using semaphores). The most significant con I see to this
is handling fault tolerance so there are no deadlocks.

I realize there are much more experienced smart people on this forum that
could shoot some holes in this approach, and I invite you to do so. My
feeling won't be hurt as long as I can learn some more.
Most of my experience is in the boring arena of Business IT (with my
earlier years in Defense with Simulators and Communication Systems).
Thanks for any reply,
   John Brown

From: Alan Kay mailto:alan.n...@yahoo.com>>
Reply-To: Alan Kay mailto:alan.n...@yahoo.com>>, 
Fundamentals of New Computing mailto:fonc@vpri.org>>
Date: Wed, 13 Feb 2013 18:51:59 -0500
To: Fundamentals of New Computing mailto:fonc@vpri.org>>
Subject: [SUSPECTED SPAM] Re: [fonc] Terminology: "Object Oriented" vs "Message 
Oriented"

Hi Barry

I like your characterization, and do think the next level also will require a 
qualitatively different approach

Cheers,

Alan

________________
From: Barry Jay mailto:barry@uts.edu.au>>
To: fonc@vpri.org<mailto:fonc@vpri.org>
Sent: Wednesday, February 13, 2013 1:13 PM
Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

Hi Alan,

the phrase I picked up on was "doing experiments". One way to think of the 
problem is that we are trying to automate the scientific process, which is a 
blend of reasoning and experiments. Most of us focus on one or the other, as in 
deductive AI versus databases of common knowledge, but the history of physics 
etc suggests that we need to develop both within a single system, e.g. a 
language that supports both higher-order programming (for strategies, etc) and 
generic queries (for conducting experiments on newly met systems).

Yours,
Barry


On 02/14/2013 02:26 AM, Alan Kay wrote:
Hi Thiago

I think you are on a good path.

One way to think about this problem is that the broker is a human programmer 
who has received a module from half way around the world that claims to provide 
important services. The programmer would confine it in an address space and 
start doing experiments with it to try to discover what it does (and/or perhaps 
how well its behavior matches up to its claims). Many of the discovery 
approaches of Lenat in AM and Eurisko could be very useful here.

Another part of the scaling of modules approach could be to require modules to 
have much better models of the environments they expect/need in order to run.

For example, suppose a module has a variable that it would like to refer to 
some external resource. Both static and dynamic typing are insufficient here 
because they are only about kinds of results rather than meanings of results.

But we could readily imagine a language in which the variable had associated 
with it a "dummy" or "stand-in" model of what is desired. It could be a slow 
version of something we are hoping to get a faster version of. It could be 
sample values and tes

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Alan Kay]

Hi Barry

I like your characterization, and do think the next level also will require a 
qualitatively different approach

Cheers,

Alan



>
> From: Barry Jay 
>To: fonc@vpri.org 
>Sent: Wednesday, February 13, 2013 1:13 PM
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
>
>Hi Alan,
>
>the phrase I picked up on was "doing experiments". One way to think of
the problem is that we are trying to automate the scientific process,
which is a blend of reasoning and experiments. Most of us focus on one
or the other, as in deductive AI versus databases of common knowledge,
but the history of physics etc suggests that we need to develop both
within a single system, e.g. a language that supports both higher-order
programming (for strategies, etc) and generic queries (for conducting
experiments on newly met systems). 
>
>Yours,
>Barry
>
>
>On 02/14/2013 02:26 AM, Alan Kay wrote: 
>Hi Thiago
>>
>>
>>I
think you are on a good path.
>>
>>
>>One
way to think about this problem is that the broker is a human
programmer who has received a module from half way around the world
that claims to provide important services. The programmer would confine
it in an address space and start doing experiments with it to try to
discover what it does (and/or perhaps how well its behavior matches up
to its claims). Many of the discovery approaches of Lenat in AM and
Eurisko could be very useful here.
>>
>>
>>Another
part of the scaling of modules approach could be to require modules to
have much better models of the environments they expect/need in order
to run.
>>
>>
>>For
example, suppose a module has a variable that it would like to refer to
some external resource. Both static and dynamic typing are insufficient
here because they are only about kinds of results rather than meanings
of results. 
>>
>>
>>But
we could readily imagine a language in which the variable had
associated with it a "dummy" or "stand-in" model of what is desired. It
could be a slow version of something we are hoping to get a faster
version of. It could be sample values and tests, etc. All of these
would be useful for debugging our module -- in fact, we could make this
a requirement of our module system, that the modules carry enough
information to allow them to be debugged with only their own model of
the environment. 
>>
>>
>>And
the more information the model has, the easier it will be for a program
to see if the model of an environment for a module matches up to
possible modules out in the environment when the system is running for
real.
>>
>>
>>Cheers,
>>
>>
>>Alan
>>
>>
>>
>>>
>>> From: Thiago Silva 
>>>To: fonc  
>>>Sent: Wednesday,
February 13, 2013 2:09 AM
>>>Subject: Re: [fonc]
Terminology: "Object Oriented" vs "Message Oriented"
>>> 
>>>Hello,
>>>
>>>as I was thinking over these problems today, here are some initial
thoughts,
>>>just to get the conversation going...
>>>
>>>
>>>The first time I read about the Method Finder and Ted's memo, I tried
to grasp
>>>the broader issue, and I'm still thinking of some interesting examples
to
>>>explore.
>>>
>>>I can see the problem of finding operations by their meanings, the
problem of
>>>finding objects by the services they provide and the overal structure
of the
>>>discovery, negotiation and binding.
>>>
>>>My feeling is that, besides using worlds as mechanism, an explicit
"discovery"
>>>context may be required (though I can't say much without further
>>>experimentations), specially when trying to figure out operations that
don't
>>>produce a distinguishable value but rather change the state of
computation
>>>(authenticating, opening a file, sending a message through the network,
etc)
>>>or when doing remote discovery.
>>>
>>>For brokering (and I'm presuming the use of such entities, as I could
not get
>>>rid of them in my mind so far), my first thought was that a chain of
brokers
>>>of some sorts could be useful in the architecture where each could have
>>>specific ways of mediating discovery and negotiation through the
"levels" (or
>>>narrowed options, providing isolation for some services. Worlds come to
mind).
>>>
>>>During the "binding time", I think it would be important that some
>>>requirements of the client could be relaxed or even be tagged optional
to
>>>allow th

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[John Carlson]

Ah.  You try to achieve a purely numeric result.  Don't forget qualitative
data and normative thinking.  Perhaps by meaning you mean qualitative
data.  Normative thinking should control reason.  That is, we shouldn't be
experimenting with destructive things.

Perhaps experimenting with meaning is trying to achieve a more humane,
comical result.  Let's not forget humor and emotion in our pursuit of
science.  We're humans after all, not computers.
On Feb 13, 2013 3:39 PM, "Barry Jay"  wrote:

> **
> Hi John,
> In the scientific tradition, experiments produce cold facts, while reason
> chooses the experiments, and uses them to test hypotheses, i.e. to extract
> meaning, so perhaps "experimenting for meaning" or "experimenting to
> recover, or discover, meaning" is closer to what I had in mind.
>
>
> On 02/14/2013 08:21 AM, John Carlson wrote:
>
> If doing experiment means experimenting with meaning, I agree.
> On Feb 13, 2013 3:17 PM, "Barry Jay"  wrote:
>
>>  Hi Alan,
>>
>> the phrase I picked up on was "doing experiments". One way to think of
>> the problem is that we are trying to automate the scientific process, which
>> is a blend of reasoning and experiments. Most of us focus on one or the
>> other, as in deductive AI versus databases of common knowledge, but the
>> history of physics etc suggests that we need to develop both within a
>> single system, e.g. a language that supports both higher-order programming
>> (for strategies, etc) and generic queries (for conducting experiments on
>> newly met systems).
>>
>> Yours,
>> Barry
>>
>>
>> On 02/14/2013 02:26 AM, Alan Kay wrote:
>>
>>  Hi Thiago
>>
>>  I think you are on a good path.
>>
>>  One way to think about this problem is that the broker is a human
>> programmer who has received a module from half way around the world that
>> claims to provide important services. The programmer would confine it in an
>> address space and start doing experiments with it to try to discover what
>> it does (and/or perhaps how well its behavior matches up to its claims).
>> Many of the discovery approaches of Lenat in AM and Eurisko could be very
>> useful here.
>>
>>  Another part of the scaling of modules approach could be to require
>> modules to have much better models of the environments they expect/need in
>> order to run.
>>
>>  For example, suppose a module has a variable that it would like to
>> refer to some external resource. Both static and dynamic typing are
>> insufficient here because they are only about kinds of results rather than
>> meanings of results.
>>
>>  But we could readily imagine a language in which the variable had
>> associated with it a "dummy" or "stand-in" model of what is desired. It
>> could be a slow version of something we are hoping to get a faster version
>> of. It could be sample values and tests, etc. All of these would be useful
>> for debugging our module -- in fact, we could make this a requirement of
>> our module system, that the modules carry enough information to allow them
>> to be debugged with only their own model of the environment.
>>
>>  And the more information the model has, the easier it will be for a
>> program to see if the model of an environment for a module matches up to
>> possible modules out in the environment when the system is running for real.
>>
>>  Cheers,
>>
>>  Alan
>>
>>--
>> *From:* Thiago Silva  
>> *To:* fonc  
>> *Sent:* Wednesday, February 13, 2013 2:09 AM
>> *Subject:* Re: [fonc] Terminology: "Object Oriented" vs "Message
>> Oriented"
>>
>> Hello,
>>
>> as I was thinking over these problems today, here are some initial
>> thoughts,
>> just to get the conversation going...
>>
>>
>> The first time I read about the Method Finder and Ted's memo, I tried to
>> grasp
>> the broader issue, and I'm still thinking of some interesting examples to
>> explore.
>>
>> I can see the problem of finding operations by their meanings, the
>> problem of
>> finding objects by the services they provide and the overal structure of
>> the
>> discovery, negotiation and binding.
>>
>> My feeling is that, besides using worlds as mechanism, an explicit
>> "discovery"
>> context may be required (though I can't say much without further
>> experimentations), specially when trying to figure out operations that
>> don't

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Barry Jay]

Hi John,
In the scientific tradition, experiments produce cold facts, while 
reason chooses the experiments, and uses them to test hypotheses, i.e. 
to extract meaning, so perhaps "experimenting for meaning" or 
"experimenting to recover, or discover, meaning" is closer to what I had 
in mind.


On 02/14/2013 08:21 AM, John Carlson wrote:
>
> If doing experiment means experimenting with meaning, I agree.
>
> On Feb 13, 2013 3:17 PM, "Barry Jay"  <mailto:barry@uts.edu.au>> wrote:
>
> Hi Alan,
>
> the phrase I picked up on was "doing experiments". One way to
> think of the problem is that we are trying to automate the
> scientific process, which is a blend of reasoning and experiments.
> Most of us focus on one or the other, as in deductive AI versus
> databases of common knowledge, but the history of physics etc
> suggests that we need to develop both within a single system, e.g.
> a language that supports both higher-order programming (for
> strategies, etc) and generic queries (for conducting experiments
> on newly met systems).
>
> Yours,
> Barry
>
>
> On 02/14/2013 02:26 AM, Alan Kay wrote:
>> Hi Thiago
>>
>> I think you are on a good path.
>>
>> One way to think about this problem is that the broker is a human
>> programmer who has received a module from half way around the
>> world that claims to provide important services. The programmer
>> would confine it in an address space and start doing experiments
>> with it to try to discover what it does (and/or perhaps how well
>> its behavior matches up to its claims). Many of the discovery
>> approaches of Lenat in AM and Eurisko could be very useful here.
>>
>> Another part of the scaling of modules approach could be to
>> require modules to have much better models of the environments
>> they expect/need in order to run.
>>
>> For example, suppose a module has a variable that it would like
>> to refer to some external resource. Both static and dynamic
>> typing are insufficient here because they are only about kinds of
>> results rather than meanings of results.
>>
>> But we could readily imagine a language in which the variable had
>> associated with it a "dummy" or "stand-in" model of what is
>> desired. It could be a slow version of something we are hoping to
>> get a faster version of. It could be sample values and tests,
>> etc. All of these would be useful for debugging our module -- in
>> fact, we could make this a requirement of our module system, that
>> the modules carry enough information to allow them to be debugged
>> with only their own model of the environment.
>>
>> And the more information the model has, the easier it will be for
>> a program to see if the model of an environment for a module
>> matches up to possible modules out in the environment when the
>> system is running for real.
>>
>> Cheers,
>>
>>     Alan
>>
>> 
>> 
>> *From:* Thiago Silva 
>> <mailto:tsi...@sourcecraft.info>
>> *To:* fonc  <mailto:fonc@vpri.org>
>> *Sent:* Wednesday, February 13, 2013 2:09 AM
>> *Subject:* Re: [fonc] Terminology: "Object Oriented" vs
>> "Message Oriented"
>>
>> Hello,
>>
>> as I was thinking over these problems today, here are some
>> initial thoughts,
>> just to get the conversation going...
>>
>>
>> The first time I read about the Method Finder and Ted's memo,
>> I tried to grasp
>> the broader issue, and I'm still thinking of some interesting
>> examples to
>> explore.
>>
>> I can see the problem of finding operations by their
>> meanings, the problem of
>> finding objects by the services they provide and the overal
>> structure of the
>> discovery, negotiation and binding.
>>
>> My feeling is that, besides using worlds as mechanism, an
>> explicit "discovery"
>> context may be required (though I can't say much without further
>> experimentations), specially when trying to figure out
>> operations that don't
>> produce a distinguishable value but rather cha

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[John Carlson]

If doing experiment means experimenting with meaning, I agree.
On Feb 13, 2013 3:17 PM, "Barry Jay"  wrote:

> **
> Hi Alan,
>
> the phrase I picked up on was "doing experiments". One way to think of the
> problem is that we are trying to automate the scientific process, which is
> a blend of reasoning and experiments. Most of us focus on one or the other,
> as in deductive AI versus databases of common knowledge, but the history of
> physics etc suggests that we need to develop both within a single system,
> e.g. a language that supports both higher-order programming (for
> strategies, etc) and generic queries (for conducting experiments on newly
> met systems).
>
> Yours,
> Barry
>
>
> On 02/14/2013 02:26 AM, Alan Kay wrote:
>
>  Hi Thiago
>
>  I think you are on a good path.
>
>  One way to think about this problem is that the broker is a human
> programmer who has received a module from half way around the world that
> claims to provide important services. The programmer would confine it in an
> address space and start doing experiments with it to try to discover what
> it does (and/or perhaps how well its behavior matches up to its claims).
> Many of the discovery approaches of Lenat in AM and Eurisko could be very
> useful here.
>
>  Another part of the scaling of modules approach could be to require
> modules to have much better models of the environments they expect/need in
> order to run.
>
>  For example, suppose a module has a variable that it would like to refer
> to some external resource. Both static and dynamic typing are insufficient
> here because they are only about kinds of results rather than meanings of
> results.
>
>  But we could readily imagine a language in which the variable had
> associated with it a "dummy" or "stand-in" model of what is desired. It
> could be a slow version of something we are hoping to get a faster version
> of. It could be sample values and tests, etc. All of these would be useful
> for debugging our module -- in fact, we could make this a requirement of
> our module system, that the modules carry enough information to allow them
> to be debugged with only their own model of the environment.
>
>  And the more information the model has, the easier it will be for a
> program to see if the model of an environment for a module matches up to
> possible modules out in the environment when the system is running for real.
>
>  Cheers,
>
>  Alan
>
>--
> *From:* Thiago Silva  
> *To:* fonc  
> *Sent:* Wednesday, February 13, 2013 2:09 AM
> *Subject:* Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
>
> Hello,
>
> as I was thinking over these problems today, here are some initial
> thoughts,
> just to get the conversation going...
>
>
> The first time I read about the Method Finder and Ted's memo, I tried to
> grasp
> the broader issue, and I'm still thinking of some interesting examples to
> explore.
>
> I can see the problem of finding operations by their meanings, the problem
> of
> finding objects by the services they provide and the overal structure of
> the
> discovery, negotiation and binding.
>
> My feeling is that, besides using worlds as mechanism, an explicit
> "discovery"
> context may be required (though I can't say much without further
> experimentations), specially when trying to figure out operations that
> don't
> produce a distinguishable value but rather change the state of computation
> (authenticating, opening a file, sending a message through the network,
> etc)
> or when doing remote discovery.
>
> For brokering (and I'm presuming the use of such entities, as I could not
> get
> rid of them in my mind so far), my first thought was that a chain of
> brokers
> of some sorts could be useful in the architecture where each could have
> specific ways of mediating discovery and negotiation through the "levels"
> (or
> narrowed options, providing isolation for some services. Worlds come to
> mind).
>
> During the "binding time", I think it would be important that some
> requirements of the client could be relaxed or even be tagged optional to
> allow the module to execute at least a subset of its features (or to
> execute
> features with suboptimal operations) when full binding isn't possible --
> though this might require special attention to guarantee that eg. disabling
> optional features don't break the execution.
>
> Further, different versions of services may require different kinds of
> pre/post-processing (eg. initialization and finalization routines). Wh

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Barry Jay]

Hi Alan,

the phrase I picked up on was "doing experiments". One way to think of 
the problem is that we are trying to automate the scientific process, 
which is a blend of reasoning and experiments. Most of us focus on one 
or the other, as in deductive AI versus databases of common knowledge, 
but the history of physics etc suggests that we need to develop both 
within a single system, e.g. a language that supports both higher-order 
programming (for strategies, etc) and generic queries (for conducting 
experiments on newly met systems).

Yours,
Barry


On 02/14/2013 02:26 AM, Alan Kay wrote:
> Hi Thiago
>
> I think you are on a good path.
>
> One way to think about this problem is that the broker is a human 
> programmer who has received a module from half way around the world 
> that claims to provide important services. The programmer would 
> confine it in an address space and start doing experiments with it to 
> try to discover what it does (and/or perhaps how well its behavior 
> matches up to its claims). Many of the discovery approaches of Lenat 
> in AM and Eurisko could be very useful here.
>
> Another part of the scaling of modules approach could be to require 
> modules to have much better models of the environments they 
> expect/need in order to run.
>
> For example, suppose a module has a variable that it would like to 
> refer to some external resource. Both static and dynamic typing are 
> insufficient here because they are only about kinds of results rather 
> than meanings of results.
>
> But we could readily imagine a language in which the variable had 
> associated with it a "dummy" or "stand-in" model of what is desired. 
> It could be a slow version of something we are hoping to get a faster 
> version of. It could be sample values and tests, etc. All of these 
> would be useful for debugging our module -- in fact, we could make 
> this a requirement of our module system, that the modules carry enough 
> information to allow them to be debugged with only their own model of 
> the environment.
>
> And the more information the model has, the easier it will be for a 
> program to see if the model of an environment for a module matches up 
> to possible modules out in the environment when the system is running 
> for real.
>
> Cheers,
>
> Alan
>
> ----------------
>     *From:* Thiago Silva 
> *To:* fonc 
> *Sent:* Wednesday, February 13, 2013 2:09 AM
> *Subject:* Re: [fonc] Terminology: "Object Oriented" vs "Message
> Oriented"
>
> Hello,
>
> as I was thinking over these problems today, here are some initial
> thoughts,
> just to get the conversation going...
>
>
> The first time I read about the Method Finder and Ted's memo, I
> tried to grasp
> the broader issue, and I'm still thinking of some interesting
> examples to
> explore.
>
> I can see the problem of finding operations by their meanings, the
> problem of
> finding objects by the services they provide and the overal
> structure of the
> discovery, negotiation and binding.
>
> My feeling is that, besides using worlds as mechanism, an explicit
> "discovery"
> context may be required (though I can't say much without further
> experimentations), specially when trying to figure out operations
> that don't
> produce a distinguishable value but rather change the state of
> computation
> (authenticating, opening a file, sending a message through the
> network, etc)
> or when doing remote discovery.
>
> For brokering (and I'm presuming the use of such entities, as I
> could not get
> rid of them in my mind so far), my first thought was that a chain
> of brokers
> of some sorts could be useful in the architecture where each could
> have
> specific ways of mediating discovery and negotiation through the
> "levels" (or
> narrowed options, providing isolation for some services. Worlds
> come to mind).
>
> During the "binding time", I think it would be important that some
> requirements of the client could be relaxed or even be tagged
> optional to
> allow the module to execute at least a subset of its features (or
> to execute
> features with suboptimal operations) when full binding isn't
> possible --
> though this might require special attention to guarantee that eg.
> disabling
> optional features don't break the execution.
>
> Further, different versions of services may r

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Rusty Mellinger]

I was imagining QuickCheck properties instead of unit tests...

On Wed, Feb 13, 2013 at 10:40 AM, Alan Kay  wrote:
> Unit tests are just a small part of the kinds of description that could be
> used and are needed.
>
> 
> From: David Harris 
> To: Alan Kay ; Fundamentals of New Computing
> 
> Sent: Wednesday, February 13, 2013 7:39 AM
>
> Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
>
> This sounds suspiciously like Unit Testing, which is basically "When I say
> this, you should answer that."Thos are precomputed answers, but could be
> computed I suppose -- so a bit like your Postscript example ... you send the
> Testing-Agent down the pipe.
>
> David
>
>
> On Wed, Feb 13, 2013 at 7:26 AM, Alan Kay  wrote:
>
> Hi Thiago
>
> I think you are on a good path.
>
> One way to think about this problem is that the broker is a human programmer
> who has received a module from half way around the world that claims to
> provide important services. The programmer would confine it in an address
> space and start doing experiments with it to try to discover what it does
> (and/or perhaps how well its behavior matches up to its claims). Many of the
> discovery approaches of Lenat in AM and Eurisko could be very useful here.
>
> Another part of the scaling of modules approach could be to require modules
> to have much better models of the environments they expect/need in order to
> run.
>
> For example, suppose a module has a variable that it would like to refer to
> some external resource. Both static and dynamic typing are insufficient here
> because they are only about kinds of results rather than meanings of
> results.
>
> But we could readily imagine a language in which the variable had associated
> with it a "dummy" or "stand-in" model of what is desired. It could be a slow
> version of something we are hoping to get a faster version of. It could be
> sample values and tests, etc. All of these would be useful for debugging our
> module -- in fact, we could make this a requirement of our module system,
> that the modules carry enough information to allow them to be debugged with
> only their own model of the environment.
>
> And the more information the model has, the easier it will be for a program
> to see if the model of an environment for a module matches up to possible
> modules out in the environment when the system is running for real.
>
> Cheers,
>
> Alan
>
> 
> From: Thiago Silva 
> To: fonc 
> Sent: Wednesday, February 13, 2013 2:09 AM
> Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
>
> Hello,
>
> as I was thinking over these problems today, here are some initial thoughts,
> just to get the conversation going...
>
>
> The first time I read about the Method Finder and Ted's memo, I tried to
> grasp
> the broader issue, and I'm still thinking of some interesting examples to
> explore.
>
> I can see the problem of finding operations by their meanings, the problem
> of
> finding objects by the services they provide and the overal structure of the
> discovery, negotiation and binding.
>
> My feeling is that, besides using worlds as mechanism, an explicit
> "discovery"
> context may be required (though I can't say much without further
> experimentations), specially when trying to figure out operations that don't
> produce a distinguishable value but rather change the state of computation
> (authenticating, opening a file, sending a message through the network, etc)
> or when doing remote discovery.
>
> For brokering (and I'm presuming the use of such entities, as I could not
> get
> rid of them in my mind so far), my first thought was that a chain of brokers
> of some sorts could be useful in the architecture where each could have
> specific ways of mediating discovery and negotiation through the "levels"
> (or
> narrowed options, providing isolation for some services. Worlds come to
> mind).
>
> During the "binding time", I think it would be important that some
> requirements of the client could be relaxed or even be tagged optional to
> allow the module to execute at least a subset of its features (or to execute
> features with suboptimal operations) when full binding isn't possible --
> though this might require special attention to guarantee that eg. disabling
> optional features don't break the execution.
>
> Further, different versions of services may require different kinds of
> pre/post-processing (eg. initialization and finalization

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Alan Kay]

Unit tests are just a small part of the kinds of description that could be used 
and are needed. 



>
> From: David Harris 
>To: Alan Kay ; Fundamentals of New Computing 
> 
>Sent: Wednesday, February 13, 2013 7:39 AM
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
>
>This sounds suspiciously like Unit Testing, which is basically "When I say 
>this, you should answer that."    Thos are precomputed answers, but could be 
>computed I suppose -- so a bit like your Postscript example ... you send the 
>Testing-Agent down the pipe.  
>
>
>David
>
>
>
>On Wed, Feb 13, 2013 at 7:26 AM, Alan Kay  wrote:
>
>Hi Thiago
>>
>>
>>I think you are on a good path.
>>
>>
>>One way to think about this problem is that the broker is a human programmer 
>>who has received a module from half way around the world that claims to 
>>provide important services. The programmer would confine it in an address 
>>space and start doing experiments with it to try to discover what it does 
>>(and/or perhaps how well its behavior matches up to its claims). Many of the 
>>discovery approaches of Lenat in AM and Eurisko could be very useful here.
>>
>>
>>Another part of the scaling of modules approach could be to require modules 
>>to have much better models of the environments they expect/need in order to 
>>run.
>>
>>
>>For example, suppose a module has a variable that it would like to refer to 
>>some external resource. Both static and dynamic typing are insufficient here 
>>because they are only about kinds of results rather than meanings of results. 
>>
>>
>>But we could readily imagine a language in which the variable had associated 
>>with it a "dummy" or "stand-in" model of what is desired. It could be a slow 
>>version of something we are hoping to get a faster version of. It could be 
>>sample values and tests, etc. All of these would be useful for debugging our 
>>module -- in fact, we could make this a requirement of our module system, 
>>that the modules carry enough information to allow them to be debugged with 
>>only their own model of the environment. 
>>
>>
>>And the more information the model has, the easier it will be for a program 
>>to see if the model of an environment for a module matches up to possible 
>>modules out in the environment when the system is running for real.
>>
>>
>>Cheers,
>>
>>
>>Alan
>>
>>
>>
>>>
>>> From: Thiago Silva 
>>>To: fonc  
>>>Sent: Wednesday, February 13, 2013 2:09 AM
>>>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
>>> 
>>>Hello,
>>>
>>>as I was thinking over these problems today, here are some initial thoughts,
>>>just to get the conversation going...
>>>
>>>
>>>The first time I read about the Method Finder and Ted's memo, I tried to 
>>>grasp
>>>the broader issue, and I'm still thinking of some interesting examples to
>>>explore.
>>>
>>>I can see the problem of finding operations by their meanings, the problem of
>>>finding objects by the services they provide and the overal structure of the
>>>discovery, negotiation and binding.
>>>
>>>My feeling is that, besides using worlds as mechanism, an explicit 
>>>"discovery"
>>>context may be required (though I can't say much without further
>>>experimentations), specially when trying to figure out operations that don't
>>>produce a distinguishable value but rather change the state of computation
>>>(authenticating, opening a file, sending a message through the network, etc)
>>>or when doing remote discovery.
>>>
>>>For brokering (and
 I'm presuming the use of such entities, as I could not get
>>>rid of them in my mind so far), my first thought was that a chain of brokers
>>>of some sorts could be useful in the architecture where each could have
>>>specific ways of mediating discovery and negotiation through the "levels" (or
>>>narrowed options, providing isolation for some services. Worlds come to 
>>>mind).
>>>
>>>During the "binding time", I think it would be important that some
>>>requirements of the client could be relaxed or even be tagged optional to
>>>allow the module to execute at least a subset of its features (or to execute

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[David Harris]

This sounds suspiciously like Unit Testing, which is basically "When I say
this, you should answer that."Thos are precomputed answers, but could
be computed I suppose -- so a bit like your Postscript example ... you send
the Testing-Agent down the pipe.

David


On Wed, Feb 13, 2013 at 7:26 AM, Alan Kay  wrote:

> Hi Thiago
>
> I think you are on a good path.
>
> One way to think about this problem is that the broker is a human
> programmer who has received a module from half way around the world that
> claims to provide important services. The programmer would confine it in an
> address space and start doing experiments with it to try to discover what
> it does (and/or perhaps how well its behavior matches up to its claims).
> Many of the discovery approaches of Lenat in AM and Eurisko could be very
> useful here.
>
> Another part of the scaling of modules approach could be to require
> modules to have much better models of the environments they expect/need in
> order to run.
>
> For example, suppose a module has a variable that it would like to refer
> to some external resource. Both static and dynamic typing are insufficient
> here because they are only about kinds of results rather than meanings of
> results.
>
> But we could readily imagine a language in which the variable had
> associated with it a "dummy" or "stand-in" model of what is desired. It
> could be a slow version of something we are hoping to get a faster version
> of. It could be sample values and tests, etc. All of these would be useful
> for debugging our module -- in fact, we could make this a requirement of
> our module system, that the modules carry enough information to allow them
> to be debugged with only their own model of the environment.
>
> And the more information the model has, the easier it will be for a
> program to see if the model of an environment for a module matches up to
> possible modules out in the environment when the system is running for real.
>
> Cheers,
>
> Alan
>
>   --------------
> *From:* Thiago Silva 
> *To:* fonc 
> *Sent:* Wednesday, February 13, 2013 2:09 AM
> *Subject:* Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
>
> Hello,
>
> as I was thinking over these problems today, here are some initial
> thoughts,
> just to get the conversation going...
>
>
> The first time I read about the Method Finder and Ted's memo, I tried to
> grasp
> the broader issue, and I'm still thinking of some interesting examples to
> explore.
>
> I can see the problem of finding operations by their meanings, the problem
> of
> finding objects by the services they provide and the overal structure of
> the
> discovery, negotiation and binding.
>
> My feeling is that, besides using worlds as mechanism, an explicit
> "discovery"
> context may be required (though I can't say much without further
> experimentations), specially when trying to figure out operations that
> don't
> produce a distinguishable value but rather change the state of computation
> (authenticating, opening a file, sending a message through the network,
> etc)
> or when doing remote discovery.
>
> For brokering (and I'm presuming the use of such entities, as I could not
> get
> rid of them in my mind so far), my first thought was that a chain of
> brokers
> of some sorts could be useful in the architecture where each could have
> specific ways of mediating discovery and negotiation through the "levels"
> (or
> narrowed options, providing isolation for some services. Worlds come to
> mind).
>
> During the "binding time", I think it would be important that some
> requirements of the client could be relaxed or even be tagged optional to
> allow the module to execute at least a subset of its features (or to
> execute
> features with suboptimal operations) when full binding isn't possible --
> though this might require special attention to guarantee that eg. disabling
> optional features don't break the execution.
>
> Further, different versions of services may require different kinds of
> pre/post-processing (eg. initialization and finalization routines). When
> abstracting a service (eg. storage) like this, I think it's when the "glue
> code" starts to require sophistication (because it needs to fill more
> blanks)...and to have it automated, the provider will need to make
> requirements to the client as well. This is where I think a common
> vocabulary
> will be more necessary.
>
> --
> Thiago
>
> Excerpts from Alan Kay's message of 2013-02-12 16:12:40 -0300:
> > Hi Jeff
> >
> &

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Alan Kay]

Hi Thiago

I think you are on a good path.

One way to think about this problem is that the broker is a human programmer 
who has received a module from half way around the world that claims to provide 
important services. The programmer would confine it in an address space and 
start doing experiments with it to try to discover what it does (and/or perhaps 
how well its behavior matches up to its claims). Many of the discovery 
approaches of Lenat in AM and Eurisko could be very useful here.

Another part of the scaling of modules approach could be to require modules to 
have much better models of the environments they expect/need in order to run.

For example, suppose a module has a variable that it would like to refer to 
some external resource. Both static and dynamic typing are insufficient here 
because they are only about kinds of results rather than meanings of results. 

But we could readily imagine a language in which the variable had associated 
with it a "dummy" or "stand-in" model of what is desired. It could be a slow 
version of something we are hoping to get a faster version of. It could be 
sample values and tests, etc. All of these would be useful for debugging our 
module -- in fact, we could make this a requirement of our module system, that 
the modules carry enough information to allow them to be debugged with only 
their own model of the environment. 

And the more information the model has, the easier it will be for a program to 
see if the model of an environment for a module matches up to possible modules 
out in the environment when the system is running for real.

Cheers,

Alan



>
> From: Thiago Silva 
>To: fonc  
>Sent: Wednesday, February 13, 2013 2:09 AM
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
>Hello,
>
>as I was thinking over these problems today, here are some initial thoughts,
>just to get the conversation going...
>
>
>The first time I read about the Method Finder and Ted's memo, I tried to grasp
>the broader issue, and I'm still thinking of some interesting examples to
>explore.
>
>I can see the problem of finding operations by their meanings, the problem of
>finding objects by the services they provide and the overal structure of the
>discovery, negotiation and binding.
>
>My feeling is that, besides using worlds as mechanism, an explicit "discovery"
>context may be required (though I can't say much without further
>experimentations), specially when trying to figure out operations that don't
>produce a distinguishable value but rather change the state of computation
>(authenticating, opening a file, sending a message through the network, etc)
>or when doing remote discovery.
>
>For brokering (and I'm presuming the use of such entities, as I could not get
>rid of them in my mind so far), my first thought was that a chain of brokers
>of some sorts could be useful in the architecture where each could have
>specific ways of mediating discovery and negotiation through the "levels" (or
>narrowed options, providing isolation for some services. Worlds come to mind).
>
>During the "binding time", I think it would be important that some
>requirements of the client could be relaxed or even be tagged optional to
>allow the module to execute at least a subset of its features (or to execute
>features with suboptimal operations) when full binding isn't possible --
>though this might require special attention to guarantee that eg. disabling
>optional features don't break the execution.
>
>Further, different versions of services may require different kinds of
>pre/post-processing (eg. initialization and finalization routines). When
>abstracting a service (eg. storage) like this, I think it's when the "glue
>code" starts to require sophistication (because it needs to fill more
>blanks)...and to have it automated, the provider will need to make
>requirements to the client as well. This is where I think a common vocabulary
>will be more necessary.
>
>--
>Thiago
>
>Excerpts from Alan Kay's message of 2013-02-12 16:12:40 -0300:
>> Hi Jeff
>> 
>> I think "intermodule communication schemes" that *really scale* is one of 
>> the most important open issues of the last 45 years or so.
>> 
>> It is one of the several "pursuits" written into the STEPS proposal that we 
>> didn't use our initial efforts on -- so we've done little to advance this 
>> over the last few years. But now that the NSF funded part of STEPS has 
>> concluded, we are planning to use much of the other strand of STEPS to look 
>> at some of these neglected issues.
>> 
>> There

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Alan Kay]

One of the original reasons for "message-based" was the simple relativistic 
one. What we decided is that trying to send messages to explicit receivers had 
real scaling problems, whereas "receiving messages" is a good idea.

Cheers,

Alan



>
> From: Eugen Leitl 
>To: Fundamentals of New Computing  
>Sent: Wednesday, February 13, 2013 5:11 AM
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
>On Tue, Feb 12, 2013 at 11:33:04AM -0700, Jeff Gonis wrote:
>> I see no one has taken Alan's bait and asked the million dollar question:
>> if you decided that messaging is no longer the right path for scaling, what
>> approach are you currently using?
>
>Classical computation doesn't allow storing multiple bits
>in the same location, so relativistic signalling introduces
>latency. Asynchronous shared-nothing message passing is
>the only thing that scales, as it matches the way how this 
>universe does things (try looking at light cones for consistent
>state for multiple writes to the same location -- this
>of course applies to cache coherency).
>
>Inversely, doing things in a different way will guarantee
>that you won't be able to scale. It's not just a good idea,
>it's the law. 
>___
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Eugen Leitl]

On Tue, Feb 12, 2013 at 11:33:04AM -0700, Jeff Gonis wrote:
> I see no one has taken Alan's bait and asked the million dollar question:
> if you decided that messaging is no longer the right path for scaling, what
> approach are you currently using?

Classical computation doesn't allow storing multiple bits
in the same location, so relativistic signalling introduces
latency. Asynchronous shared-nothing message passing is
the only thing that scales, as it matches the way how this 
universe does things (try looking at light cones for consistent
state for multiple writes to the same location -- this
of course applies to cache coherency).

Inversely, doing things in a different way will guarantee
that you won't be able to scale. It's not just a good idea,
it's the law. 
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Thiago Silva]

ute force is used here (Ted executes all the methods that could fit 
> in the system safely to see what they do.)
> 
> One of the solutions at PARC for dealing with a part of the problem is the 
> idea of "send an agent, not a message". It was quickly found that defining 
> file formats for all the different things that could be printed on the new 
> laser printer was not scaling well. The solution was to send a program that 
> would just execute safely and blindly in the printer -- the printer would 
> then just print out the bit bin. This was known as PostScript when it came 
> out in the world.
> 
> The "Trickles" idea from Cornell has much of the same flavor.
> 
> One possible starting place is to notice that there are lots more terms that 
> people can use than the few that are needed to make a powerful compact 
> programming language. So why not try to describe meanings and match on 
> meanings -- and let there be not just matching (which is like a password) but 
> "negotiation", which is what a discovery agent does.
> 
> And so forth. I think this is a difficult but doable problem -- it's easier 
> than AI, but has some tinges of it.
> 
> Got any ideas?
> 
> Cheers,
> 
> Alan
> 
> >
> > From: Jeff Gonis 
> >To: Alan Kay  
> >Cc: Fundamentals of New Computing  
> >Sent: Tuesday, February 12, 2013 10:33 AM
> >Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> > 
> >
> >I see no one has taken Alan's bait and asked the million dollar question: if 
> >you decided that messaging is no longer the right path for scaling, what 
> >approach are you currently using?
> >I would assume that FONC is the current approach, meaning, at the risk of 
> >grossly over-simplifying and sounding ignorant, "problem oriented languages" 
> >allowing for compact expression of meaning.  But even here, FONC struck me 
> >as providing vastly better ways of creating code that, at its core, still 
> >used messaging for robustness, etc, rather than using something entirely 
> >different.
> >Have I completely misread the FONC projects? And if not messaging, what 
> >approach are you currently using to handle scalability?
> >A little more history ...
> >
> >
> >The first Smalltalk (-72) was "modern" (as used below), and similar to 
> >Erlang in several ways -- for example, messages were received with 
> >"structure and pattern matching", etc. The language was extended using the 
> >same mechanisms ...
> >
> >
> >Cheers,
> >
> >
> >
> >Alan
> >
> >
> >
> >>
> >> From: Brian Rice 
> >>To: Fundamentals of New Computing  
> >>Sent: Tuesday, February 12, 2013 8:54 AM
> >>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> >> 
> >>
> >>Independently of the originally-directed historical intent, I'll pose my 
> >>own quick perspective.
> >>
> >>Perhaps a contrast with Steve Yegge's Kingdom of Nouns essay would help:
> >>http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
> >>
> >>
> >>
> >>The modern post-Erlang sense of message-oriented computing has to do with 
> >>messages with structure and pattern-matching, where error-handling isn't 
> >>about sequential, nested access, but more about independent structures 
> >>dealing with untrusted noise.
> >>
> >>
> >>Anyway, treating the messages as first-class objects (in the Lisp sense) is 
> >>what gets you there:
> >>http://www.erlang.org/doc/getting_started/conc_prog.html
> >>
> >>
> >>
> >>
> >>
> >>
> >>On Tue, Feb 12, 2013 at 7:15 AM, Loup Vaillant  
> >>wrote:
> >>
> >>This question was prompted by a quote by Joe Armstrong about OOP[1].
> >>>It is for Alan Kay, but I'm totally fine with a relevant link.  Also,
> >>>"I don't know" and "I don't have time for this" are perfectly okay.
> >>>
> >>>Alan, when the term "Object oriented" you coined has been hijacked by
> >>>Java and Co, you made clear that you were mainly about messages, not
> >>>classes. My model of you even says that Erlang is far more OO than Java.
> >>>
> >>>Then why did you chose the term "object" instead of "message" in the
> >>>first place?  Was there a specific reason for your preference, or did
> >>>you simply not bother foreseeing any terminology issue? (20/20 hindsight 
> >>>and such.)
> >>>
> >>>Bonus question: if you had choose "message" instead, do you think it
> >>>would have been hijacked too?
> >>>
> >>>Thanks,
> >>>Loup.
> >>>
> >>>
> >>>[1]: http://news.ycombinator.com/item?id=5205976
> >>>     (This is for reference, you don't really need to read it.)
> >>>___
> >>>fonc mailing list
> >>>fonc@vpri.org
> >>>http://vpri.org/mailman/listinfo/fonc
> >>>
> >>
> >>
> >>
> >>-- 
> >>-Brian T. Rice 
> >>___
> >>fonc mailing list
> >>fonc@vpri.org
> >>http://vpri.org/mailman/listinfo/fonc
> >>
> >>
> >>
> >___
> >fonc mailing list
> >fonc@vpri.org
> >http://vpri.org/mailman/listinfo/fonc
> >
> >
> >
> >
-- 
[]'s
Thiago Silva
http://www.metareload.com

"We are either doing something or we are not; 'talking about' is a subset of 
'not'."
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Miles Fidelman]

John Carlson wrote:


Is there a computer language (yes I realize games do this) that work 
like human languages?  With features like misdirection, 
misinterpretation, volume, persuasion?  Can we come up with a social 
language for computers?  No, I'm not talking lojban, I'm talking 
something something semantically and/or syntactically ambiguous.  
Maybe lingodroids is close. More work in this area would be interesting.




Well PPL (Paranoid Programming Language) might come close. 
http://zzo38computer.org/backup/paranoid-programming-language.html :-)


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[David Hussman]

Could not resist the pun

iTypos expected from iPhone; please forgive

Mobile: 6127434923

On Feb 12, 2013, at 8:50, "Brown, John Mickey"  
wrote:

> Dude….   You said shiny "objects"….Lol.
> 
> Messaging certainly seems to have a larger focus with multi-core, many-core, 
> and cloud computing concepts (that itself is morphing into shiny objects).
> I also enjoy these history lessons and discussions.
> 
> John
> 
> From: David Hussman 
> Reply-To: Fundamentals of New Computing 
> Date: Tue, 12 Feb 2013 11:36:35 -0500
> To: 'Alan Kay' , 'Fundamentals of New Computing' 
> 
> Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
> Alan,
>  
> Thanks for the thoughtful words / history. I am a lurker on this group and I 
> dig seeing this kind of dialog during times when I am so often surrounded by 
> bright shiny object types.
>  
> David
>  
> From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of Alan 
> Kay
> Sent: Tuesday, February 12, 2013 10:23 AM
> To: Fundamentals of New Computing
> Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
>  
> Hi Loup
>  
> I think how this happened has already been described in "The Early History of 
> Smalltalk". 
>  
> But 
>  
> In the Fall of 1966, Sketchpad was what got me started thinking about 
> "representing concepts as whole things". Simula, a week later, provided a 
> glimpse of how one could "deal with issues that couldn't be done wonderfully 
> with constraints and solving" (namely, you could hide procedures inside the 
> entities). 
>  
> This triggered off many thoughts in a few minutes, bringing in "ideas that 
> seemed similar" from biology, math (algebras), logic (Carnap's intensional 
> logic), philosophy (Plato's "Ideas"), hardware (running multiple active units 
> off a bus), systems design (the use of virtual machines in time-sharing), and 
> networking (the ARPA community was getting ready to do the ARPAnet). Bob 
> Barton had pronounced that "recursive design is making the parts have the 
> same powers as the wholes", which for the first time I was able to see was 
> really powerful if the wholes and the parts were entire computers hardware or 
> software or some mixture.
>  
> The latter was hugely important to me because it allowed a "universal 
> simulation system" to be created from just a few ideas that would cover 
> everything and every other kind of thing.
>  
> During this period I had no label for what I was doing, including "this thing 
> I was doing", I was just doing.
>  
> A few months later someone asked me what I was doing, and I didn't think 
> about the answer -- I was still trying to see how the synthesis of ideas 
> could be pulled off without a lot of machinery (kind of the math stage of the 
> process).
>  
> Back then, there was already a term in use called "data driven programming". 
> This is where "data" contains info that will help find appropriate 
> procedures. 
>  
> And the term "objects" was also used for "composite data" i.e. blocks of 
> storage with different fields containing values of various kinds. This came 
> naturally from "card images" (punched cards were usually 80 or more 
> characters long and divided into fields). 
>  
> At some point someone (probably in the 50s) decided to use some of the fields 
> to help the logic of plug board programming and "drive" the processes off the 
> cards rather than "just processing" them.
>  
> So if you looked at how Sketchpad was implemented you would see, in the terms 
> of the day: "objects that were data driven". Ivan gives Doug Ross credit for 
> his "plex structures", which were an MIT way to think about these ideas. 
> Sketchpad also used "threaded lists" in its blocks (this was not a great idea 
> but it was popular back then -- Simula later took this up as well).
>  
> So I just said "object oriented programming" and went back to work.
>  
> Later I regretted this (and some of the other labels that were also put in 
> service) after the ideas worked out nicely and were very powerful for us at 
> PARC. 
>  
> The success of the ideas made what we were doing popular, and people wanted 
> to be a part of it. This led to using the term "object oriented" as a 
> designer jeans label for pretty much anything (there was even an 
> "object-oriented" COBOL!). This appropriation of labels without content is a 
>

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Alan Kay]

Hi Miles

I wouldn't characterize it that way.

Much of today's way of doing "object-oriented" programming with regard to 
simulating data-structures is due to C++ and Bjarn Stroustrup's explicit intent 
to "do to C, what Simula did to Algol". He says clearly in the first C++ 
documentation that he is going to follow Simula by making a preprocessor for C, 
and not try to do a late-bound integrated system like Smalltalk.

The idea of simulating data structures using procedures goes way back -- the 
B5000 had it in hardware! -- and I think it was a multiple invention to see 
this as useful in objects. My first investigation (also recounted in TEHOS) was 
to "fix" one thing the B5000 couldn't quite do, which was to simulate a "sparse 
array" efficiently using objects.

When Simula 67 later appeared, one of their examples was Class String.

My way of thinking about it was much more influenced by Sketchpad and Biology. 
Objects should be like active entities -- Dan Ingalls later characterized the 
feeling of OO programming as being more like training intelligent entities than 
as a puppet master having to pull all the wires directly. So my thought was 
that sending a message should be requesting a goal to be carried out, etc.


What seemed to be really nice -- and still does -- was the simulation idea. 
This meant that you could make one OO system and that you could simulate all 
the components. What if you didn't know how to make a particular smart object 
"the right way"? No problem, you could write a kluge for now, stick it inside 
the object to hide it, and make it look the way it should on the outside. What 
if you couldn't think of anything better than a data structure for a classic 
algorithm? No problem, you could simulate the data structure.

From my bio background, this seemed really nice. You want to do things in terms 
of cells and tissues, but you might have to resort to lesser organizations of 
atoms to make them. The idea in the OOP languages we did was that you should 
really take advantage of the simulation possibilities to design as strongly as 
possible, and then you had a universal material that could allow every 
qualitative level of structure and process to be done.

So this would again be very "actor-like" -- and I thought "actors" were just a 
great name for this way of doing things.

My own personal thoughts about what was accomplished are completely intertwined 
with what our entire group was able to do in a few years at PARC. I would give 
us credit for a very high level combination of "computer science" and "software 
engineering" and "human centered design" and "commingled software and 
hardware", etc. The accomplishment was the group's accomplishment. And this 
whole (to me at least) was a lot more interesting than just a language idea.

I hasten to redirect personal praise to the group accomplishment whenever it 
happens.


I think this is also true for the larger ARPA-PARC community, and why it was 
able to accomplish so much at so many levels.

The "awards to individuals" structure beloved of other fields and of 
journalists completely misses the nature of this process. Any recognition 
should be like "World Series" rings -- everybody gets one, and that's it.

Best wishes,

Alan



>____________
> From: Miles Fidelman 
>To: Fundamentals of New Computing  
>Sent: Tuesday, February 12, 2013 1:09 PM
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
>Hi Alan,
>
>Is it fair to say that the path you took with Smalltalk led to today's object 
>model of data structures, associated methods, and inheritance, with either a 
>single thread-of-control, or small numbers of threads; while the Actor model 
>led (perhaps not directly) to massive concurrency and Erlang?  (I'm still 
>waiting for something that looks like Smalltalk meets Erlang.)
>
>Cheers,
>
>Miles
>
>Alan Kay wrote:
>> Hi Miles
>> 
>> (Again "The Early History of Smalltalk" has some of this history ...)
>> 
>> It is unfair to Carl Hewitt to say that "Actors were his reaction to 
>> Smalltalk-72" (because he had been thinking early thoughts from other 
>> influences). And I had been doing a lot of thinking about the import of his 
>> "Planner" language.
>> 
>> But that is the simplest way of stating the facts and the ordering.
>> 
>> ST-72 and the early Actors follow on were very similar. The Smalltalk that 
>> didn't get made, "-71", was a kind of merge of the object idea, Logo, and 
>> Carl's Planner system (which predated Prolog and was in many respects more 
>> powerful). Planner used &

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[John Carlson]

Is there a computer language (yes I realize games do this) that work like
human languages?  With features like misdirection, misinterpretation,
volume, persuasion?  Can we come up with a social language for computers?
No, I'm not talking lojban, I'm talking something something semantically
and/or syntactically ambiguous.  Maybe lingodroids is close.  More work in
this area would be interesting.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Miles Fidelman]

Hi Alan,

Is it fair to say that the path you took with Smalltalk led to today's 
object model of data structures, associated methods, and inheritance, 
with either a single thread-of-control, or small numbers of threads; 
while the Actor model led (perhaps not directly) to massive concurrency 
and Erlang?  (I'm still waiting for something that looks like Smalltalk 
meets Erlang.)


Cheers,

Miles

Alan Kay wrote:

Hi Miles

(Again "The Early History of Smalltalk" has some of this history ...)

It is unfair to Carl Hewitt to say that "Actors were his reaction to 
Smalltalk-72" (because he had been thinking early thoughts from other 
influences). And I had been doing a lot of thinking about the import 
of his "Planner" language.


But that is the simplest way of stating the facts and the ordering.

ST-72 and the early Actors follow on were very similar. The Smalltalk 
that didn't get made, "-71", was a kind of merge of the object idea, 
Logo, and Carl's Planner system (which predated Prolog and was in many 
respects more powerful). Planner used "pattern-directed invocation" 
and I thought you could both receive messages with it if it were made 
the interface of an object, and also use it for deduction. 
Smalltalk-72 was a bit of an accident


The divergence later was that we got a bit dirtier as we made a real 
system that you could program a real system in. Actors got cleaner as 
they looked at many interesting theoretical possibilities for 
distributed computing etc. My notion of "object oriented" would now 
seem to be very actor-like.


Cheers,

Alan



*From:* Miles Fidelman 
*To:* Fundamentals of New Computing 
*Sent:* Tuesday, February 12, 2013 11:05 AM
    *Subject:* Re: [fonc] Terminology: "Object Oriented" vs "Message
Oriented"

Alan Kay wrote:
> A little more history ...
>
> The first Smalltalk (-72) was "modern" (as used below), and
similar to Erlang in several ways -- for example, messages were
received with "structure and pattern matching", etc. The language
was extended using the same mechanisms ...

Alan,

As I recall, some of your early writings on Smalltalk sounded very
actor-like - i.e., objects as processes, with lots of messages
floating around, rather than a sequential thread-of-control model.
Or is my memory just getting fuzzy?  In any case, I'm surprised
that the term "actor" hasn't popped up in this thread, along with
"object" and "messaging."

Miles Fidelman



-- In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

___
fonc mailing list
fonc@vpri.org <mailto:fonc@vpri.org>
http://vpri.org/mailman/listinfo/fonc




___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Alan Kay]

Hi Miles

(Again "The Early History of Smalltalk" has some of this history ...)

It is unfair to Carl Hewitt to say that "Actors were his reaction to 
Smalltalk-72" (because he had been thinking early thoughts from other 
influences). And I had been doing a lot of thinking about the import of his 
"Planner" language.

But that is the simplest way of stating the facts and the ordering. 

ST-72 and the early Actors follow on were very similar. The Smalltalk that 
didn't get made, "-71", was a kind of merge of the object idea, Logo, and 
Carl's Planner system (which predated Prolog and was in many respects more 
powerful). Planner used "pattern-directed invocation" and I thought you could 
both receive messages with it if it were made the interface of an object, and 
also use it for deduction. Smalltalk-72 was a bit of an accident

The divergence later was that we got a bit dirtier as we made a real system 
that you could program a real system in. Actors got cleaner as they looked at 
many interesting theoretical possibilities for distributed computing etc. My 
notion of "object oriented" would now seem to be very actor-like.

Cheers,

Alan




>
> From: Miles Fidelman 
>To: Fundamentals of New Computing  
>Sent: Tuesday, February 12, 2013 11:05 AM
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
>Alan Kay wrote:
>> A little more history ...
>> 
>> The first Smalltalk (-72) was "modern" (as used below), and similar to 
>> Erlang in several ways -- for example, messages were received with 
>> "structure and pattern matching", etc. The language was extended using the 
>> same mechanisms ...
>
>Alan,
>
>As I recall, some of your early writings on Smalltalk sounded very actor-like 
>- i.e., objects as processes, with lots of messages floating around, rather 
>than a sequential thread-of-control model. Or is my memory just getting fuzzy? 
> In any case, I'm surprised that the term "actor" hasn't popped up in this 
>thread, along with "object" and "messaging."
>
>Miles Fidelman
>
>
>
>-- In theory, there is no difference between theory and practice.
>In practice, there is.    Yogi Berra
>
>___
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Alan Kay]

Hi Jeff

I think "intermodule communication schemes" that *really scale* is one of the 
most important open issues of the last 45 years or so.

It is one of the several "pursuits" written into the STEPS proposal that we 
didn't use our initial efforts on -- so we've done little to advance this over 
the last few years. But now that the NSF funded part of STEPS has concluded, we 
are planning to use much of the other strand of STEPS to look at some of these 
neglected issues.

There are lots of facets, and one has to do with messaging. The idea that 
"sending a message" has scaling problems is one that has been around for quite 
a while. It was certainly something that we pondered at PARC 35 years ago, and 
it was an issue earlier for both the ARPAnet and its offspring: the Internet.

Several members of this list have pointed this out also.

There are similar scaling problems with the use of tags in XML and EMI etc. 
which have to be agreed on somehow


Part of the problem is that for vanilla sends, the sender has to know the 
receiver in some fashion. This starts requiring the interior of a module to 
know too much if this is a front line mechanism.

This leads to wanting to do something more like LINDA "coordination" or 
"publish and subscribe" where there are pools of producers and consumers who 
don't have to know explicitly about each other. A "send" is now a general 
request for a resource. But the vanilla approaches here still require that the 
"sender" and "receiver" have a fair amount of common knowledge (because the 
matching is usually done on "terms in common").

For example, in order to invoke a module that will compute the sine of an 
angle, do you and the receiver both have to agree about the term "sine"? In APL 
I think the name of this function is "circle 1" and in Smalltalk it's 
"degreeSin", etc. 

Ted Kaehler solved this problem some years ago in Squeak Smalltalk with his 
"message finder". For example, if you enter 3. 4. 7 Squeak will instantly come 
back with:
   3 bitOr: 4 --> 7
   3 bitXor: 4 --> 7
   3 + 4 --> 7

For the sine example you would enter 30. 0.5 and Squeak will come up with: 
   30 degreeSin --> 0.5

The method finder is acting a bit like Doug Lenat's "discovery" systems. Simple 
brute force is used here (Ted executes all the methods that could fit in the 
system safely to see what they do.)

One of the solutions at PARC for dealing with a part of the problem is the idea 
of "send an agent, not a message". It was quickly found that defining file 
formats for all the different things that could be printed on the new laser 
printer was not scaling well. The solution was to send a program that would 
just execute safely and blindly in the printer -- the printer would then just 
print out the bit bin. This was known as PostScript when it came out in the 
world.

The "Trickles" idea from Cornell has much of the same flavor.

One possible starting place is to notice that there are lots more terms that 
people can use than the few that are needed to make a powerful compact 
programming language. So why not try to describe meanings and match on meanings 
-- and let there be not just matching (which is like a password) but 
"negotiation", which is what a discovery agent does.

And so forth. I think this is a difficult but doable problem -- it's easier 
than AI, but has some tinges of it.

Got any ideas?

Cheers,

Alan




>____
> From: Jeff Gonis 
>To: Alan Kay  
>Cc: Fundamentals of New Computing  
>Sent: Tuesday, February 12, 2013 10:33 AM
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
>
>I see no one has taken Alan's bait and asked the million dollar question: if 
>you decided that messaging is no longer the right path for scaling, what 
>approach are you currently using?
>I would assume that FONC is the current approach, meaning, at the risk of 
>grossly over-simplifying and sounding ignorant, "problem oriented languages" 
>allowing for compact expression of meaning.  But even here, FONC struck me as 
>providing vastly better ways of creating code that, at its core, still used 
>messaging for robustness, etc, rather than using something entirely different.
>Have I completely misread the FONC projects? And if not messaging, what 
>approach are you currently using to handle scalability?
>A little more history ...
>
>
>The first Smalltalk (-72) was "modern" (as used below), and similar to Erlang 
>in several ways -- for example, messages were received with "structure and 
>pattern matching", etc. The language was extended using the same mechanisms ...
>
>
>Cheers,
>
>
>

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Miles Fidelman]

Alan Kay wrote:

A little more history ...

The first Smalltalk (-72) was "modern" (as used below), and similar to 
Erlang in several ways -- for example, messages were received with 
"structure and pattern matching", etc. The language was extended using 
the same mechanisms ...


Alan,

As I recall, some of your early writings on Smalltalk sounded very 
actor-like - i.e., objects as processes, with lots of messages floating 
around, rather than a sequential thread-of-control model. Or is my 
memory just getting fuzzy?  In any case, I'm surprised that the term 
"actor" hasn't popped up in this thread, along with "object" and 
"messaging."


Miles Fidelman



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Jeff Gonis]

I see no one has taken Alan's bait and asked the million dollar question:
if you decided that messaging is no longer the right path for scaling, what
approach are you currently using?

I would assume that FONC is the current approach, meaning, at the risk of
grossly over-simplifying and sounding ignorant, "problem oriented
languages" allowing for compact expression of meaning.  But even here, FONC
struck me as providing vastly better ways of creating code that, at its
core, still used messaging for robustness, etc, rather than using something
entirely different.

Have I completely misread the FONC projects? And if not messaging, what
approach are you currently using to handle scalability?
A little more history ...

The first Smalltalk (-72) was "modern" (as used below), and similar to
Erlang in several ways -- for example, messages were received with
"structure and pattern matching", etc. The language was extended using the
same mechanisms ...

Cheers,

Alan

  --
*From:* Brian Rice 
*To:* Fundamentals of New Computing 
*Sent:* Tuesday, February 12, 2013 8:54 AM
*Subject:* Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

Independently of the originally-directed historical intent, I'll pose my
own quick perspective.

Perhaps a contrast with Steve Yegge's Kingdom of Nouns essay would help:
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

The modern post-Erlang sense of message-oriented computing has to do with
messages with structure and pattern-matching, where error-handling isn't
about sequential, nested access, but more about independent structures
dealing with untrusted noise.

Anyway, treating the messages as first-class objects (in the Lisp sense) is
what gets you there:
http://www.erlang.org/doc/getting_started/conc_prog.html



On Tue, Feb 12, 2013 at 7:15 AM, Loup Vaillant  wrote:

This question was prompted by a quote by Joe Armstrong about OOP[1].
It is for Alan Kay, but I'm totally fine with a relevant link.  Also,
"I don't know" and "I don't have time for this" are perfectly okay.

Alan, when the term "Object oriented" you coined has been hijacked by
Java and Co, you made clear that you were mainly about messages, not
classes. My model of you even says that Erlang is far more OO than Java.

Then why did you chose the term "object" instead of "message" in the
first place?  Was there a specific reason for your preference, or did
you simply not bother foreseeing any terminology issue? (20/20 hindsight
and such.)

Bonus question: if you had choose "message" instead, do you think it
would have been hijacked too?

Thanks,
Loup.


[1]: http://news.ycombinator.com/item?id=5205976
 (This is for reference, you don't really need to read it.)
__**_
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc




-- 
-Brian T. Rice

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc



___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Göran Krampe]

Hi!

On 02/12/2013 04:15 PM, Loup Vaillant wrote:

This question was prompted by a quote by Joe Armstrong about OOP[1].


Sidenote, the article Joe wrote on OO which I subsequently bashed:

http://goran.krampe.se/2009/06/26/joe-is-wrong/

...but I met him later and he knows OO quite well these days - and is 
also friends with several of our luminaries.


regards, Göran
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Alan Kay]

A little more history ...

The first Smalltalk (-72) was "modern" (as used below), and similar to Erlang 
in several ways -- for example, messages were received with "structure and 
pattern matching", etc. The language was extended using the same mechanisms ...

Cheers,


Alan



>
> From: Brian Rice 
>To: Fundamentals of New Computing  
>Sent: Tuesday, February 12, 2013 8:54 AM
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
>
>Independently of the originally-directed historical intent, I'll pose my own 
>quick perspective.
>
>Perhaps a contrast with Steve Yegge's Kingdom of Nouns essay would help:
>http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
>
>
>
>The modern post-Erlang sense of message-oriented computing has to do with 
>messages with structure and pattern-matching, where error-handling isn't about 
>sequential, nested access, but more about independent structures dealing with 
>untrusted noise.
>
>
>Anyway, treating the messages as first-class objects (in the Lisp sense) is 
>what gets you there:
>http://www.erlang.org/doc/getting_started/conc_prog.html
>
>
>
>
>
>
>On Tue, Feb 12, 2013 at 7:15 AM, Loup Vaillant  wrote:
>
>This question was prompted by a quote by Joe Armstrong about OOP[1].
>>It is for Alan Kay, but I'm totally fine with a relevant link.  Also,
>>"I don't know" and "I don't have time for this" are perfectly okay.
>>
>>Alan, when the term "Object oriented" you coined has been hijacked by
>>Java and Co, you made clear that you were mainly about messages, not
>>classes. My model of you even says that Erlang is far more OO than Java.
>>
>>Then why did you chose the term "object" instead of "message" in the
>>first place?  Was there a specific reason for your preference, or did
>>you simply not bother foreseeing any terminology issue? (20/20 hindsight and 
>>such.)
>>
>>Bonus question: if you had choose "message" instead, do you think it
>>would have been hijacked too?
>>
>>Thanks,
>>Loup.
>>
>>
>>[1]: http://news.ycombinator.com/item?id=5205976
>>     (This is for reference, you don't really need to read it.)
>>___
>>fonc mailing list
>>fonc@vpri.org
>>http://vpri.org/mailman/listinfo/fonc
>>
>
>
>
>-- 
>-Brian T. Rice 
>___
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Loup Vaillant]

Alan Kay a écrit :

Hi Loup

I think how this happened has already been described in "The Early
History of Smalltalk".

But 

[Incredibly detailed and thoughtful response]


Whoa. Thank you.

Loup

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Brian Rice]

Independently of the originally-directed historical intent, I'll pose my
own quick perspective.

Perhaps a contrast with Steve Yegge's Kingdom of Nouns essay would help:
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

The modern post-Erlang sense of message-oriented computing has to do with
messages with structure and pattern-matching, where error-handling isn't
about sequential, nested access, but more about independent structures
dealing with untrusted noise.

Anyway, treating the messages as first-class objects (in the Lisp sense) is
what gets you there:
http://www.erlang.org/doc/getting_started/conc_prog.html



On Tue, Feb 12, 2013 at 7:15 AM, Loup Vaillant  wrote:

> This question was prompted by a quote by Joe Armstrong about OOP[1].
> It is for Alan Kay, but I'm totally fine with a relevant link.  Also,
> "I don't know" and "I don't have time for this" are perfectly okay.
>
> Alan, when the term "Object oriented" you coined has been hijacked by
> Java and Co, you made clear that you were mainly about messages, not
> classes. My model of you even says that Erlang is far more OO than Java.
>
> Then why did you chose the term "object" instead of "message" in the
> first place?  Was there a specific reason for your preference, or did
> you simply not bother foreseeing any terminology issue? (20/20 hindsight
> and such.)
>
> Bonus question: if you had choose "message" instead, do you think it
> would have been hijacked too?
>
> Thanks,
> Loup.
>
>
> [1]: 
> http://news.ycombinator.com/**item?id=5205976
>  (This is for reference, you don't really need to read it.)
> __**_
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/**listinfo/fonc
>



-- 
-Brian T. Rice
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Brown, John Mickey]

Dude….   You said shiny "objects"….Lol.

Messaging certainly seems to have a larger focus with multi-core, many-core, 
and cloud computing concepts (that itself is morphing into shiny objects).
I also enjoy these history lessons and discussions.

John

From: David Hussman mailto:david.huss...@devjam.com>>
Reply-To: Fundamentals of New Computing mailto:fonc@vpri.org>>
Date: Tue, 12 Feb 2013 11:36:35 -0500
To: 'Alan Kay' mailto:alan.n...@yahoo.com>>, 'Fundamentals 
of New Computing' mailto:fonc@vpri.org>>
Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

Alan,

Thanks for the thoughtful words / history. I am a lurker on this group and I 
dig seeing this kind of dialog during times when I am so often surrounded by 
bright shiny object types.

David

From: fonc-boun...@vpri.org<mailto:fonc-boun...@vpri.org> 
[mailto:fonc-boun...@vpri.org] On Behalf Of Alan Kay
Sent: Tuesday, February 12, 2013 10:23 AM
To: Fundamentals of New Computing
Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

Hi Loup

I think how this happened has already been described in "The Early History of 
Smalltalk".

But 

In the Fall of 1966, Sketchpad was what got me started thinking about 
"representing concepts as whole things". Simula, a week later, provided a 
glimpse of how one could "deal with issues that couldn't be done wonderfully 
with constraints and solving" (namely, you could hide procedures inside the 
entities).

This triggered off many thoughts in a few minutes, bringing in "ideas that 
seemed similar" from biology, math (algebras), logic (Carnap's intensional 
logic), philosophy (Plato's "Ideas"), hardware (running multiple active units 
off a bus), systems design (the use of virtual machines in time-sharing), and 
networking (the ARPA community was getting ready to do the ARPAnet). Bob Barton 
had pronounced that "recursive design is making the parts have the same powers 
as the wholes", which for the first time I was able to see was really powerful 
if the wholes and the parts were entire computers hardware or software or some 
mixture.

The latter was hugely important to me because it allowed a "universal 
simulation system" to be created from just a few ideas that would cover 
everything and every other kind of thing.

During this period I had no label for what I was doing, including "this thing I 
was doing", I was just doing.

A few months later someone asked me what I was doing, and I didn't think about 
the answer -- I was still trying to see how the synthesis of ideas could be 
pulled off without a lot of machinery (kind of the math stage of the process).

Back then, there was already a term in use called "data driven programming". 
This is where "data" contains info that will help find appropriate procedures.

And the term "objects" was also used for "composite data" i.e. blocks of 
storage with different fields containing values of various kinds. This came 
naturally from "card images" (punched cards were usually 80 or more characters 
long and divided into fields).

At some point someone (probably in the 50s) decided to use some of the fields 
to help the logic of plug board programming and "drive" the processes off the 
cards rather than "just processing" them.

So if you looked at how Sketchpad was implemented you would see, in the terms 
of the day: "objects that were data driven". Ivan gives Doug Ross credit for 
his "plex structures", which were an MIT way to think about these ideas. 
Sketchpad also used "threaded lists" in its blocks (this was not a great idea 
but it was popular back then -- Simula later took this up as well).

So I just said "object oriented programming" and went back to work.

Later I regretted this (and some of the other labels that were also put in 
service) after the ideas worked out nicely and were very powerful for us at 
PARC.

The success of the ideas made what we were doing popular, and people wanted to 
be a part of it. This led to using the term "object oriented" as a designer 
jeans label for pretty much anything (there was even an "object-oriented" 
COBOL!). This appropriation of labels without content is a typical pop culture 
"fantasy football" syndrome.

PARC was an integral part of the ARPA community, the last gasp of which in the 
70s was designing the Internet via a design group that contained PARC people 
(PARC had actually already done an "internetwork" -- called PUP -- with 
"gateways" (routers) to interconnect Ethernetworks and other networks within 
Xerox).

It was clear to all in this community from the mid-60s onward that how 
"messaging" was

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Alan Kay]

I left out the Lisp influences. I didn't know Lisp when the original thoughts 
were happening, but a few years later, Lisp turned out to be a huge positive 
factor in working out both how things could be done, and also provided ideas 
and contexts for this kind of thinking. For example, the first Smalltalk was 
really an exercise in "apply"

Cheers,

Alan



>
> From: David Hussman 
>To: 'Alan Kay' ; 'Fundamentals of New Computing' 
> 
>Sent: Tuesday, February 12, 2013 8:36 AM
>Subject: RE: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
>
>Alan,
> 
>Thanks for the thoughtful words / history. I am a lurker on this group and I 
>dig seeing this kind of dialog during times when I am so often surrounded by 
>bright shiny object types.
> 
>David
> 
>From:fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of Alan Kay
>Sent: Tuesday, February 12, 2013 10:23 AM
>To: Fundamentals of New Computing
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
>Hi Loup
> 
>I think how this happened has already been described in "The Early History of 
>Smalltalk". 
> 
>But 
> 
>In the Fall of 1966, Sketchpad was what got me started thinking about 
>"representing concepts as whole things". Simula, a week later, provided a 
>glimpse of how one could "deal with issues that couldn't be done wonderfully 
>with constraints and solving" (namely, you could hide procedures inside the 
>entities). 
> 
>This triggered off many thoughts in a few minutes, bringing in "ideas that 
>seemed similar" from biology, math (algebras), logic (Carnap's intensional 
>logic), philosophy (Plato's "Ideas"), hardware (running multiple active units 
>off a bus), systems design (the use of virtual machines in time-sharing), and 
>networking (the ARPA community was getting ready to do the ARPAnet). Bob 
>Barton had pronounced that "recursive design is making the parts have the same 
>powers as the wholes", which for the first time I was able to see was really 
>powerful if the wholes and the parts were entire computers hardware or 
>software or some mixture.
> 
>The latter was hugely important to me because it allowed a "universal 
>simulation system" to be created from just a few ideas that would cover 
>everything and every other kind of thing.
> 
>During this period I had no label for what I was doing, including "this thing 
>I was doing", I was just doing.
> 
>A few months later someone asked me what I was doing, and I didn't think about 
>the answer -- I was still trying to see how the synthesis of ideas could be 
>pulled off without a lot of machinery (kind of the math stage of the process).
> 
>Back then, there was already a term in use called "data driven programming". 
>This is where "data" contains info that will help find appropriate procedures. 
> 
>And the term "objects" was also used for "composite data" i.e. blocks of 
>storage with different fields containing values of various kinds. This came 
>naturally from "card images" (punched cards were usually 80 or more characters 
>long and divided into fields). 
> 
>At some point someone (probably in the 50s) decided to use some of the fields 
>to help the logic of plug board programming and "drive" the processes off the 
>cards rather than "just processing" them.
> 
>So if you looked at how Sketchpad was implemented you would see, in the terms 
>of the day: "objects that were data driven". Ivan gives Doug Ross credit for 
>his "plex structures", which were an MIT way to think about these ideas. 
>Sketchpad also used "threaded lists" in its blocks (this was not a great idea 
>but it was popular back then -- Simula later took this up as well).
> 
>So I just said "object oriented programming" and went back to work.
> 
>Later I regretted this (and some of the other labels that were also put in 
>service) after the ideas worked out nicely and were very powerful for us at 
>PARC. 
> 
>The success of the ideas made what we were doing popular, and people wanted to 
>be a part of it. This led to using the term "object oriented" as a designer 
>jeans label for pretty much anything (there was even an "object-oriented" 
>COBOL!). This appropriation of labels without content is a typical pop culture 
>"fantasy football" syndrome.
> 
>PARC was an integral part of the ARPA community, the last gasp of which in the 
>70s was designing the Internet via a design

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[David Hussman]

Alan,

 

Thanks for the thoughtful words / history. I am a lurker on this group and I
dig seeing this kind of dialog during times when I am so often surrounded by
bright shiny object types.

 

David

 

From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of Alan
Kay
Sent: Tuesday, February 12, 2013 10:23 AM
To: Fundamentals of New Computing
Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

 

Hi Loup

 

I think how this happened has already been described in "The Early History
of Smalltalk". 

 

But 

 

In the Fall of 1966, Sketchpad was what got me started thinking about
"representing concepts as whole things". Simula, a week later, provided a
glimpse of how one could "deal with issues that couldn't be done wonderfully
with constraints and solving" (namely, you could hide procedures inside the
entities). 

 

This triggered off many thoughts in a few minutes, bringing in "ideas that
seemed similar" from biology, math (algebras), logic (Carnap's intensional
logic), philosophy (Plato's "Ideas"), hardware (running multiple active
units off a bus), systems design (the use of virtual machines in
time-sharing), and networking (the ARPA community was getting ready to do
the ARPAnet). Bob Barton had pronounced that "recursive design is making the
parts have the same powers as the wholes", which for the first time I was
able to see was really powerful if the wholes and the parts were entire
computers hardware or software or some mixture.

 

The latter was hugely important to me because it allowed a "universal
simulation system" to be created from just a few ideas that would cover
everything and every other kind of thing.

 

During this period I had no label for what I was doing, including "this
thing I was doing", I was just doing.

 

A few months later someone asked me what I was doing, and I didn't think
about the answer -- I was still trying to see how the synthesis of ideas
could be pulled off without a lot of machinery (kind of the math stage of
the process).

 

Back then, there was already a term in use called "data driven programming".
This is where "data" contains info that will help find appropriate
procedures. 

 

And the term "objects" was also used for "composite data" i.e. blocks of
storage with different fields containing values of various kinds. This came
naturally from "card images" (punched cards were usually 80 or more
characters long and divided into fields). 

 

At some point someone (probably in the 50s) decided to use some of the
fields to help the logic of plug board programming and "drive" the processes
off the cards rather than "just processing" them.

 

So if you looked at how Sketchpad was implemented you would see, in the
terms of the day: "objects that were data driven". Ivan gives Doug Ross
credit for his "plex structures", which were an MIT way to think about these
ideas. Sketchpad also used "threaded lists" in its blocks (this was not a
great idea but it was popular back then -- Simula later took this up as
well).

 

So I just said "object oriented programming" and went back to work.

 

Later I regretted this (and some of the other labels that were also put in
service) after the ideas worked out nicely and were very powerful for us at
PARC. 

 

The success of the ideas made what we were doing popular, and people wanted
to be a part of it. This led to using the term "object oriented" as a
designer jeans label for pretty much anything (there was even an
"object-oriented" COBOL!). This appropriation of labels without content is a
typical pop culture "fantasy football" syndrome.

 

PARC was an integral part of the ARPA community, the last gasp of which in
the 70s was designing the Internet via a design group that contained PARC
people (PARC had actually already done an "internetwork" -- called PUP --
with "gateways" (routers) to interconnect Ethernetworks and other networks
within Xerox).

 

It was clear to all in this community from the mid-60s onward that how
"messaging" was done was one of the keys to achieving scaling. This is why
"what I was working on" had "messages" as the larger coordination idea
(rather than the subset of "calls").

 

At PARC we wanted to do a complete personal computing system on the Alto,
which was a microcoded ~150ns cycle CPU with 16 program counters and 64k
16bit words of memory that cycled at ~750ns (where half of this memory was
used for the bit-map of the display). The next level memory was not a
swapping disk but a slower removable disk with about 2.5MBytes capacity.

 

The good news was that the Alto was fast enough to run Smalltalk byte codes
and bitblt, etc. to allo

Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Alan Kay]

 was to not manifest a "message" unless someone wanted to see it -- this 
was part of the magic of Dan Ingalls' design).

So I think the problem with "messaging" was partly that it was the more subtle 
and invisible idea and this "verb part") got lost because the representational 
"noun part" got all the attention. (And we generally don't think of noun-like 
things as "in process".) This is part of the big problem in "OOP" today, 
because it is mostly a complicated way of making new data structures whose 
fields are munged by "setters".


Back to your original question, it *might* have helped to have better 
terminology. The Simula folks tried this in the first Simula, but their choice 
of English words was confusing (they used "Activity" for "Class" and "Process" 
for "Instance"). This is almost good and much more in keeping with what should 
be the philosophical underpinnings of this kind of design. 

After being told that no one had understood this (I and two other grad students 
had to read the machine code listing of the Simula compiler to understand its 
documentation!), the Nygaard and Dahl chose "Class" and "Instance" for Simula 
67. I chose these for Smalltalk also because why multiply terms? (I should have 
chosen better terms here also.)

To sum up, besides the tiny computers we had to use back then, we didn't have a 
good enough theory of messaging -- we did have a start that was based on Dave 
Fisher's "Control Definition Language" CMU 1970 thesis. But then we got 
overwhelmed by the excitement of being able to make personal computing on the 
Alto. A few years later I decided that "sending messages" was not a good 
scaling idea, and that something more general to get needed resources "from the 
outside" needed to be invented.


Cheers,

Alan



>
> From: Loup Vaillant 
>To: Fundamentals of New Computing  
>Sent: Tuesday, February 12, 2013 7:15 AM
>Subject: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> 
>This question was prompted by a quote by Joe Armstrong about OOP[1].
>It is for Alan Kay, but I'm totally fine with a relevant link.  Also,
>"I don't know" and "I don't have time for this" are perfectly okay.
>
>Alan, when the term "Object oriented" you coined has been hijacked by
>Java and Co, you made clear that you were mainly about messages, not
>classes. My model of you even says that Erlang is far more OO than Java.
>
>Then why did you chose the term "object" instead of "message" in the
>first place?  Was there a specific reason for your preference, or did
>you simply not bother foreseeing any terminology issue? (20/20 hindsight and 
>such.)
>
>Bonus question: if you had choose "message" instead, do you think it
>would have been hijacked too?
>
>Thanks,
>Loup.
>
>
>[1]: http://news.ycombinator.com/item?id=5205976
>     (This is for reference, you don't really need to read it.)
>___
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

[fonc] Terminology: "Object Oriented" vs "Message Oriented"

[Loup Vaillant]

This question was prompted by a quote by Joe Armstrong about OOP[1].
It is for Alan Kay, but I'm totally fine with a relevant link.  Also,
"I don't know" and "I don't have time for this" are perfectly okay.

Alan, when the term "Object oriented" you coined has been hijacked by
Java and Co, you made clear that you were mainly about messages, not
classes. My model of you even says that Erlang is far more OO than Java.

Then why did you chose the term "object" instead of "message" in the
first place?  Was there a specific reason for your preference, or did
you simply not bother foreseeing any terminology issue? (20/20 hindsight 
and such.)


Bonus question: if you had choose "message" instead, do you think it
would have been hijacked too?

Thanks,
Loup.


[1]: http://news.ycombinator.com/item?id=5205976
 (This is for reference, you don't really need to read it.)
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc