Re: [fonc] Building blocks and use of text

[Casey Ransberger]

The next big thing probably won't be some version of Minecraft, even if
Minecraft is really awesome. OTOH, you and your kids can prove me wrong
today with Minecraft Raspberry Pi Edition, which is free, and comes with
_source code_.

http://mojang.com/2013/02/minecraft-pi-edition-is-available-for-download/



On Wed, Feb 13, 2013 at 5:55 PM, John Carlson  wrote:

> Miles wrote:
> > There's a pretty good argument to be made that what "works" are powerful
> building blocks that can be combined in lots of different ways;
>
> So the next big thing will be some version of minecraft?  Or perhaps the
> older toontalk?  Agentcubes?  What is the right 3D metaphor?  Does anyone
> have a comfortable metaphor?  It would seem like if there was an open,
> federated MMO system that supported object lifecycles, we would have
> something.  Do we have an "object web" yet, or are we stuck with text
> forever, with all the nasty security vunerabilities involved?  Yes I agree
> that we lost something when we moved to the web.  Perhaps we need to step
> away from the document model purely for security reasons.
>
> What's the alternative?  Scratch and Alice?  Storing/transmitting ASTs?
> Does our reliance on https/ssl/tls which is based on streams limit us? When
> are we going to stop making streams secure and start making secure network
> objects?  Object-capability security anyone?
>
> Are we stuck with documents because they are the best thing for debugging?
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>


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

Re: [fonc] Building blocks and use of text

[John Carlson]

There is more to the DIS (Distributed *Interactive* Simulation) than I
originally thought.  I found this in the X3D standard:
http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/dis.html
if
one can set up isNetworkWriter, it would seem like anything on the network
would be writable by that node.

I understand the attraction for using encryption on streams of data for
efficiency reasons.  Can one compare E vats http://erights.org/ to DIS?

Sorry if I keep bothering people.  Sometimes the best way for me to learn
is start a conversation.

John


On Wed, Feb 13, 2013 at 11:18 PM, John Carlson  wrote:

> Ah, I thought DIS only sent id, position, orientation, velocity and
> acceleration.  Do objects own their properties, or can anyone on the
> network provide them?
>
> I've heard of people mixing X3D with DIS.  I thought that X3D provided all
> the modelling and visualization, and DIS provided the above.  X3D is a
> textual language.  When asked about security on the X3D-public list, the
> suggestion was to use session idsyeah, right, one key for the whole
> browser.
>
>
> On Wed, Feb 13, 2013 at 8:58 PM, Miles Fidelman <
> mfidel...@meetinghouse.net> wrote:
>
>> John Carlson wrote:
>>
>>>
>>> Miles wrote:
>>> > There's a pretty good argument to be made that what "works" are
>>> powerful building blocks that can be combined in lots of different ways;
>>>
>>> So the next big thing will be some version of minecraft?  Or perhaps the
>>> older toontalk?  Agentcubes?  What is the right 3D metaphor?  Does anyone
>>> have a comfortable metaphor?  It would seem like if there was an open,
>>> federated MMO system that supported object lifecycles, we would have
>>> something.  Do we have an "object web" yet, or are we stuck with text
>>> forever, with all the nasty security vunerabilities involved?  Yes I agree
>>> that we lost something when we moved to the web.  Perhaps we need to step
>>> away from the document model purely for security reasons.
>>>
>>>
>> DIS (Distributed Internet Simulation) or HLA (High Level Architecture) -
>> both are distributed, real-time object protocols for managing very complex
>> virtual worlds (specifically, military simulations and wargames).
>>
>>
>>
>> --
>> 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] Paranoid programming language

[Casey Ransberger]

That's a good name for a programming language!

On Wed, Feb 13, 2013 at 4:20 AM, David Pennell wrote:

> Malboge (http://en.wikipedia.org/wiki/Malbolge) was featured on an
> episode of Elementary.  It's named after the eighth circle of hell in
> Dante's Inferno.
>
> Malbolge was so difficult to understand when it arrived that it took two
>> years for the first Malbolge program to appear. The first Malbolge program
>> was not written by a human being, it was generated by a beam 
>> searchalgorithm designed by Andrew 
>> Cooke and implemented in
>> Lisp 
>>
>
> -david
>
>
> On Wed, Feb 13, 2013 at 6:06 AM, Miles Fidelman <
> mfidel...@meetinghouse.net> wrote:
>
>> Well, for evocative names, there's always Brainfuck (
>> http://en.wikipedia.org/wiki/**Brainfuck)
>> - which is a real language, with derivatives even.  And the name is truly
>> accurate. :-)
>>
>> John Carlson wrote:
>>
>>>
>>> Ah first time I came across a language with such an evocative name.
>>>  Since I am too paranoid to click on a link, perhaps you could summarize. I
>>> did a search and it seemed to indicate that the language was a joke.  Sigh.
>>>
>>> On Feb 12, 2013 7:26 PM, "Miles Fidelman" 
>>> >> mfidelman@**meetinghouse.net >> wrote:
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> __**_
>>> 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
>>
>> --
>> -david 
>>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>


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

Re: [fonc] Building blocks and use of text

[John Carlson]

Ah, I thought DIS only sent id, position, orientation, velocity and
acceleration.  Do objects own their properties, or can anyone on the
network provide them?

I've heard of people mixing X3D with DIS.  I thought that X3D provided all
the modelling and visualization, and DIS provided the above.  X3D is a
textual language.  When asked about security on the X3D-public list, the
suggestion was to use session idsyeah, right, one key for the whole
browser.


On Wed, Feb 13, 2013 at 8:58 PM, Miles Fidelman
wrote:

> John Carlson wrote:
>
>>
>> Miles wrote:
>> > There's a pretty good argument to be made that what "works" are
>> powerful building blocks that can be combined in lots of different ways;
>>
>> So the next big thing will be some version of minecraft?  Or perhaps the
>> older toontalk?  Agentcubes?  What is the right 3D metaphor?  Does anyone
>> have a comfortable metaphor?  It would seem like if there was an open,
>> federated MMO system that supported object lifecycles, we would have
>> something.  Do we have an "object web" yet, or are we stuck with text
>> forever, with all the nasty security vunerabilities involved?  Yes I agree
>> that we lost something when we moved to the web.  Perhaps we need to step
>> away from the document model purely for security reasons.
>>
>>
> DIS (Distributed Internet Simulation) or HLA (High Level Architecture) -
> both are distributed, real-time object protocols for managing very complex
> virtual worlds (specifically, military simulations and wargames).
>
>
>
> --
> 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] Building blocks and use of text

[Miles Fidelman]

John Carlson wrote:


Miles wrote:
> There's a pretty good argument to be made that what "works" are 
powerful building blocks that can be combined in lots of different ways;


So the next big thing will be some version of minecraft?  Or perhaps 
the older toontalk?  Agentcubes?  What is the right 3D metaphor?  Does 
anyone have a comfortable metaphor?  It would seem like if there was 
an open, federated MMO system that supported object lifecycles, we 
would have something.  Do we have an "object web" yet, or are we stuck 
with text forever, with all the nasty security vunerabilities 
involved?  Yes I agree that we lost something when we moved to the 
web.  Perhaps we need to step away from the document model purely for 
security reasons.




DIS (Distributed Internet Simulation) or HLA (High Level Architecture) - 
both are distributed, real-time object protocols for managing very 
complex virtual worlds (specifically, military simulations and wargames).




--
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] Design of web, POLs for rules. Fuzz testing nile

[Alan Kay]

My suggestion is to learn a little about biology and anthropology and media as 
it intertwines with human thought, then check back in.



>
> From: Miles Fidelman 
>To: Fundamentals of New Computing  
>Sent: Wednesday, February 13, 2013 5:56 PM
>Subject: Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
> 
>Hi Alan
>> 
>> First, my email was not about Ted Nelson, Doug Engelbart or what massively 
>> distributed media should be like. It was strictly about architectures that 
>> allow a much wider range of possibilities.
>
>Ahh... but my argument is that the architecture of the current web is SIMPLER 
>than earlier concepts but has proven more powerful (or at least more 
>effective).
>
>> 
>> Second, can you see that your argument really doesn't hold? This is because 
>> it even more justifies oral speech rather than any kind of writing -- and 
>> for hundreds of thousands of years rather than a few thousand. The invention 
>> of writing was very recent and unusual. Most of the humans who have lived on 
>> the earth never learned it. Using your logic, humans should have stuck with 
>> oral modes and not bothered to go through all the work to learn to read and 
>> write.
>
>Actually, no.  Oral communication begat oral communication at a distance - via 
>radio, telephone, VoIP, etc. - all of which have pretty much plateaued in 
>terms of functionality.  Written communication is (was) something new and 
>different, and the web is a technological extension of written communication.  
>My hypothesis is that, as long as we're dealing with interfaces that look a 
>lot like paper (i.e., screens), we may have plateaued as to what's effective 
>in augmenting written communication with technology.  Simple building blocks 
>that we can mix and match in lots of ways.
>
>Now... if we want to talk about new forms of communication (telepathy?), or 
>new kinds of interfaces (3d immersion, neural interfaces that align with some 
>of the kinds of parallel/visual thinking that we do internally), then we start 
>to need to talk about qualitatively different kinds of technological 
>augmentation.
>
>Of course there is a counter-argument to be made that our kids engage in a new 
>and different form of cognition - by dint of continual immersion in large 
>numbers of parallel information streams.  Then again, we seem to be talking 
>lots of short messages (twitter, texting), and there does seem to be a lot of 
>evidence that multi-tasking and information overload are counter-productive 
>(do we really need society-wide ADHD?).
>
>> 
>> There is also more than a tinge of "false Darwin" in your argument. 
>> Evolutionary-like processes don't optimize, they just find fits to the 
>> environment and ecology that exists.
>
>Umm.. that sounds a lot like optimizing to me.  In any case, there's the 
>question of what are we trying to optimize?  That seems to be both an 
>evolutionary question and one of emergent behaviors.
>> The real question here is not "what do humans want?" (consumerism finds this 
>> and supplies it to the general detriment of society), but "what do humans 
>> *need*?" (even if what we need takes a lot of learning to take on).
>
>Now that's truly a false argument.  "Consumerism," as we tend to view it, is 
>driven by producers, advertising, and creation of false needs.
>
>
>Cheers,
>
>Miles
>
>-- 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] Design of web, POLs for rules. Fuzz testing nile

[John Carlson]

On Feb 13, 2013 7:57 PM, "Miles Fidelman" 
wrote:

> Ahh... but my argument is that the architecture of the current web is
SIMPLER than earlier concepts but has proven more powerful (or at least
more effective).

If you believe that, I've got a perl script I want to sell you.   Nothing
prevents complexity, except debugging it.  I believe that text is easier to
debug than alternative.  To make anything easier debug, I recommend
programming by demonstration.  I would like to see more such systems.  How
about you?
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Design of web, POLs for rules. Fuzz testing nile

[Miles Fidelman]

Hi Alan


First, my email was not about Ted Nelson, Doug Engelbart or what 
massively distributed media should be like. It was strictly about 
architectures that allow a much wider range of possibilities.


Ahh... but my argument is that the architecture of the current web is 
SIMPLER than earlier concepts but has proven more powerful (or at least 
more effective).




Second, can you see that your argument really doesn't hold? This is 
because it even more justifies oral speech rather than any kind of 
writing -- and for hundreds of thousands of years rather than a few 
thousand. The invention of writing was very recent and unusual. Most 
of the humans who have lived on the earth never learned it. Using your 
logic, humans should have stuck with oral modes and not bothered to go 
through all the work to learn to read and write.


Actually, no.  Oral communication begat oral communication at a distance 
- via radio, telephone, VoIP, etc. - all of which have pretty much 
plateaued in terms of functionality.  Written communication is (was) 
something new and different, and the web is a technological extension of 
written communication.  My hypothesis is that, as long as we're dealing 
with interfaces that look a lot like paper (i.e., screens), we may have 
plateaued as to what's effective in augmenting written communication 
with technology.  Simple building blocks that we can mix and match in 
lots of ways.


Now... if we want to talk about new forms of communication (telepathy?), 
or new kinds of interfaces (3d immersion, neural interfaces that align 
with some of the kinds of parallel/visual thinking that we do 
internally), then we start to need to talk about qualitatively different 
kinds of technological augmentation.


Of course there is a counter-argument to be made that our kids engage in 
a new and different form of cognition - by dint of continual immersion 
in large numbers of parallel information streams.  Then again, we seem 
to be talking lots of short messages (twitter, texting), and there does 
seem to be a lot of evidence that multi-tasking and information overload 
are counter-productive (do we really need society-wide ADHD?).




There is also more than a tinge of "false Darwin" in your argument. 
Evolutionary-like processes don't optimize, they just find fits to the 
environment and ecology that exists.


Umm.. that sounds a lot like optimizing to me.  In any case, there's the 
question of what are we trying to optimize?  That seems to be both an 
evolutionary question and one of emergent behaviors.
The real question here is not "what do humans want?" (consumerism 
finds this and supplies it to the general detriment of society), but 
"what do humans *need*?" (even if what we need takes a lot of learning 
to take on).


Now that's truly a false argument.  "Consumerism," as we tend to view 
it, is driven by producers, advertising, and creation of false needs.



Cheers,

Miles

--
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] Building blocks and use of text

[John Carlson]

Miles wrote:
> There's a pretty good argument to be made that what "works" are powerful
building blocks that can be combined in lots of different ways;

So the next big thing will be some version of minecraft?  Or perhaps the
older toontalk?  Agentcubes?  What is the right 3D metaphor?  Does anyone
have a comfortable metaphor?  It would seem like if there was an open,
federated MMO system that supported object lifecycles, we would have
something.  Do we have an "object web" yet, or are we stuck with text
forever, with all the nasty security vunerabilities involved?  Yes I agree
that we lost something when we moved to the web.  Perhaps we need to step
away from the document model purely for security reasons.

What's the alternative?  Scratch and Alice?  Storing/transmitting ASTs?
Does our reliance on https/ssl/tls which is based on streams limit us? When
are we going to stop making streams secure and start making secure network
objects?  Object-capability security anyone?

Are we stuck with documents because they are the best thing for debugging?
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Design of web, POLs for rules. Fuzz testing nile

[Alan Kay]

Hi Miles

First, my email was not about Ted Nelson, Doug Engelbart or what massively 
distributed media should be like. It was strictly about architectures that 
allow a much wider range of possibilities.

Second, can you see that your argument really doesn't hold? This is because it 
even more justifies oral speech rather than any kind of writing -- and for 
hundreds of thousands of years rather than a few thousand. The invention of 
writing was very recent and unusual. Most of the humans who have lived on the 
earth never learned it. Using your logic, humans should have stuck with oral 
modes and not bothered to go through all the work to learn to read and write.

There is also more than a tinge of "false Darwin" in your argument. 
Evolutionary-like processes don't optimize, they just find fits to the 
environment and ecology that exists. The real question here is not "what do 
humans want?" (consumerism finds this and supplies it to the general detriment 
of society), but "what do humans *need*?" (even if what we need takes a lot of 
learning to take on).





>
> From: Miles Fidelman 
>To: Fundamentals of New Computing  
>Sent: Wednesday, February 13, 2013 4:58 PM
>Subject: Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
> 
>Alan Kay wrote:
>> 
>> Or you could look at the actual problem "a web" has to solve, which is to 
>> present arbitrary information to a user that comes from any of several 
>> billion sources. Looked at from this perspective we can see that the current 
>> web design could hardly be more wrong headed. For example, what is the 
>> probability that we can make an authoring app that has all the features 
>> needed by billions of producers?
>
>Hmmm let me take an opposing view here, at least for the purpose of 
>playing devil's advocate:
>
>1. Paper and ink have served for 1000s of years, and with the addition of the 
>printing press and libraries have served to distribute and preserve 
>information, from several billion sources, for an awfully long time.
>
>2. If one actually looks at what people use when generating and distributing 
>information it tends to be essentially "smarter paper" - word processors, 
>spreadsheets, powerpoint slides; and when we look at distribution systems, it 
>comes down to email and the electronic equivalent of file rooms and libraries.
>
>Sure, we've added additional media types to the mix, but the basic model 
>hasn't changed all that much.  Pretty much all the more complicated 
>technologies people have come up with don't actually work that well, or get 
>used that much.  Even in the web world, single direction hyperlinks dominate 
>(remember all the complicated, bi-directional links that Ted Nelson came up 
>with).  And when it comes to "groupware," what dominates seems to be chat and 
>twitter.
>
>There's a pretty good argument to be made that what "works" are powerful 
>building blocks that can be combined in lots of different ways; driven by some 
>degree of natural selection and evolution. (Where the web is concerned, first 
>there was ftp, then techinfo, then gopher, and now the web.  Simple mashups 
>seem to have won out over more complicated service oriented architectures.  We 
>might well have plateaued.)
>
>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] Design of web, POLs for rules. Fuzz testing nile

[Miles Fidelman]

Alan Kay wrote:


Or you could look at the actual problem "a web" has to solve, which is 
to present arbitrary information to a user that comes from any of 
several billion sources. Looked at from this perspective we can see 
that the current web design could hardly be more wrong headed. For 
example, what is the probability that we can make an authoring app 
that has all the features needed by billions of producers?


Hmmm let me take an opposing view here, at least for the purpose of 
playing devil's advocate:


1. Paper and ink have served for 1000s of years, and with the addition 
of the printing press and libraries have served to distribute and 
preserve information, from several billion sources, for an awfully long 
time.


2. If one actually looks at what people use when generating and 
distributing information it tends to be essentially "smarter paper" - 
word processors, spreadsheets, powerpoint slides; and when we look at 
distribution systems, it comes down to email and the electronic 
equivalent of file rooms and libraries.


Sure, we've added additional media types to the mix, but the basic model 
hasn't changed all that much.  Pretty much all the more complicated 
technologies people have come up with don't actually work that well, or 
get used that much.  Even in the web world, single direction hyperlinks 
dominate (remember all the complicated, bi-directional links that Ted 
Nelson came up with).  And when it comes to "groupware," what dominates 
seems to be chat and twitter.


There's a pretty good argument to be made that what "works" are powerful 
building blocks that can be combined in lots of different ways; driven 
by some degree of natural selection and evolution. (Where the web is 
concerned, first there was ftp, then techinfo, then gopher, and now the 
web.  Simple mashups seem to have won out over more complicated service 
oriented architectures.  We might well have plateaued.)


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"

[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 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 

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
>> 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
>>

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

[Brown, John Mickey]

>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


On 2/13/13 5:09 AM, "Thiago Silva"  wrote:

>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 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 th

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"  > 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

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). 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 co

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 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

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 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 "intermod

Re: [fonc] Design of web, POLs for rules. Fuzz testing nile

[John Carlson]

I've done some postscript programming.  I guess I see the shading languages
more a successor to postscript than any revival of display postscript and
its onerous licensing.  People are already trying to put javascript into
the gpu.  I haven't seen nile, but I assume that it works with gpus.  What
I am aiming for is something higher level...perhaps I need to take some art
classes.  Ocw?
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Design of web, POLs for rules. Fuzz testing nile

[Alan Kay]

Or the (earlier) Smalltalk Models Views Controllers mechanism which had a 
dynamic language with dynamic graphics to allow quite a bit of flexibility with 
arbitrary "models". 



>
> From: David Harris 
>To: Alan Kay ; Fundamentals of New Computing 
> 
>Sent: Wednesday, February 13, 2013 7:44 AM
>Subject: Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
> 
>
>Alan --
>
>
>Yes, we seem to slowly getting back the the NeWS (Network extensible Windowing 
>System) paradigm which used a modified Display Postscript to allow the 
>intelligence, including user input, to live in the terminal (as opposed to the 
>X-Windows model).  But I am sure I am teaching my grandmother to suck eggs, 
>here, sorry :-) .
>
>
>David
>[[ NeWS = Network extensible Windowing System 
>http://en.wikipedia.org/wiki/NeWS ]]
>
>
>On Wed, Feb 13, 2013 at 7:37 AM, Alan Kay  wrote:
>
>Hi John
>>
>>
>>Or you could look at the actual problem "a web" has to solve, which is to 
>>present arbitrary information to a user that comes from any of several 
>>billion sources. Looked at from this perspective we can see that the current 
>>web design could hardly be more wrong headed. For example, what is the 
>>probability that we can make an authoring app that has all the features 
>>needed by billions of producers?
>>
>>
>>One conclusion could be that the web/browser is not an app but should be a 
>>kind of operating system that should be set up to safely execute anything 
>>from anywhere and to present the results in forms understandable by the 
>>end-user.
>>
>>
>>After literally decades of trying to add more and more features and not yet 
>>matching up to the software than ran on the machines the original browser was 
>>done on, they are slowly coming around to the idea that they should be safely 
>>executing programs written by others. It has only been in the last few years 
>>-- with Native Client in Chrome -- that really fast programs can be safely 
>>downloaded as executables without having to have permission of a SysAdmin.
>>
>>
>>So another way to look at all this is to ask what such an "OS" really needs 
>>to have to allow all in the world to make their own media and have it used by 
>>others ...
>>
>>
>>Cheers,
>>
>>
>>Alan
>>
>>
>>
>>>
>>> From: John Carlson 
>>>To: Fundamentals of New Computing  
>>>Sent: Tuesday, February 12, 2013 9:00 PM
>>>Subject: [fonc] Design of web, POLs for rules. Fuzz testing nile
>>> 
>>>
>>>Although I have read very little about the design of the web, things are 
>>>starting to gel in my mind.  At the lowest level lies the static or 
>>>declarative part of the web.  The html, dom, xml and json are the main 
>>>languages used in the declarative part.  Layered on top of this is the 
>>>dynamic or procedural part of the web.  Javascript and xslt are the main 
>>>languages in the procedural part.   The final level is the constraints or 
>>>rule based part of the web, normally called stylesheets.  The languages in 
>>>the rule based web are css1, 2, 3 and xsl. Jquery provides a way to apply 
>>>operations in this arena.  I am excluding popular server side 
>>>languages...too many.
>>>What I am wondering is what is the best way to incorporate rules into a 
>>>language.  Vrml has routes.  Uml has ocl. Is avoiding if statements and 
>>>for/while loops the goal of rules languages--that syntax?  That is, do a 
>>>query or find, and apply the operations or rules to all returned values.
>>>Now, if I wanted to apply probabilistic or fuzzy rules to the dom, that 
>>>seems fairly straightforward.  Fuzz testing does this moderately well.  Has 
>>>there been attempts at better fuzz testing? Fuzz about fuzz?  Or is brute 
>>>force best?
>>>We've also seen probablistic parser generators, correct?
>>>But what about probablistic rules?  Can we design an ultimate website w/o a 
>>>designer?  Can we use statistics to create a great solitaire player--i have 
>>>a pretty good stochastic solitaire player for one version of solitaire...how 
>>>about others?  How does one create a great set of rules?  One can create 
>>>great rule POLs, but where are the authors?  Something like cameron browne's 
>>>thesis seems great for grid games.  He is quite prolific.  Can we apply the 
>>>same logic to card games? Web sites?  We have "The Nature of Order" by c. 
>>>Alexander.  Are there nile designers or fuzz testers/genetic algorithms for 
>>>nile?
>>>Is fuzz testing a by product of nile design...should it be?
>>>If you want to check out the state of the art for dungeons and dragons POLs 
>>>check out fantasy grounds...xml hell.  We can do better.
>>>___
>>>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 m

Re: [fonc] Design of web, POLs for rules. Fuzz testing nile

[David Harris]

Alan --

Yes, we seem to slowly getting back the the NeWS (Network extensible
Windowing System) paradigm which used a modified Display Postscript to
allow the intelligence, including user input, to live in the terminal (as
opposed to the X-Windows model).  But I am sure I am teaching my
grandmother to suck eggs, here, sorry :-) .

David
[[ NeWS = Network extensible Windowing System
http://en.wikipedia.org/wiki/NeWS ]]

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

> Hi John
>
> Or you could look at the actual problem "a web" has to solve, which is to
> present arbitrary information to a user that comes from any of several
> billion sources. Looked at from this perspective we can see that the
> current web design could hardly be more wrong headed. For example, what is
> the probability that we can make an authoring app that has all the features
> needed by billions of producers?
>
> One conclusion could be that the web/browser is not an app but should be a
> kind of operating system that should be set up to safely execute anything
> from anywhere and to present the results in forms understandable by the
> end-user.
>
> After literally decades of trying to add more and more features and not
> yet matching up to the software than ran on the machines the original
> browser was done on, they are slowly coming around to the idea that they
> should be *safely executing programs written by others*. It has only been
> in the last few years -- with Native Client in Chrome -- that really fast
> programs can be safely downloaded as executables without having to have
> permission of a SysAdmin.
>
> So another way to look at all this is to ask what such an "OS" really
> needs to have to allow all in the world to make their own media and have it
> used by others ...
>
> Cheers,
>
> Alan
>
>   --
> *From:* John Carlson 
> *To:* Fundamentals of New Computing 
> *Sent:* Tuesday, February 12, 2013 9:00 PM
> *Subject:* [fonc] Design of web, POLs for rules. Fuzz testing nile
>
> Although I have read very little about the design of the web, things are
> starting to gel in my mind.  At the lowest level lies the static or
> declarative part of the web.  The html, dom, xml and json are the main
> languages used in the declarative part.  Layered on top of this is the
> dynamic or procedural part of the web.  Javascript and xslt are the main
> languages in the procedural part.   The final level is the constraints or
> rule based part of the web, normally called stylesheets.  The languages in
> the rule based web are css1, 2, 3 and xsl. Jquery provides a way to apply
> operations in this arena.  I am excluding popular server side
> languages...too many.
> What I am wondering is what is the best way to incorporate rules into a
> language.  Vrml has routes.  Uml has ocl. Is avoiding if statements and
> for/while loops the goal of rules languages--that syntax?  That is, do a
> query or find, and apply the operations or rules to all returned values.
> Now, if I wanted to apply probabilistic or fuzzy rules to the dom, that
> seems fairly straightforward.  Fuzz testing does this moderately well.  Has
> there been attempts at better fuzz testing? Fuzz about fuzz?  Or is brute
> force best?
> We've also seen probablistic parser generators, correct?
> But what about probablistic rules?  Can we design an ultimate website w/o
> a designer?  Can we use statistics to create a great solitaire player--i
> have a pretty good stochastic solitaire player for one version of
> solitaire...how about others?  How does one create a great set of rules?
> One can create great rule POLs, but where are the authors?  Something like
> cameron browne's thesis seems great for grid games.  He is quite prolific.
> Can we apply the same logic to card games? Web sites?  We have "The Nature
> of Order" by c. Alexander.  Are there nile designers or fuzz
> testers/genetic algorithms for nile?
> Is fuzz testing a by product of nile design...should it be?
> If you want to check out the state of the art for dungeons and dragons
> POLs check out fantasy grounds...xml hell.  We can do better.
>
> ___
> 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"

[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
>>>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 th

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
> >
> > 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 

Re: [fonc] Design of web, POLs for rules. Fuzz testing nile

[Alan Kay]

Hi John

Or you could look at the actual problem "a web" has to solve, which is to 
present arbitrary information to a user that comes from any of several billion 
sources. Looked at from this perspective we can see that the current web design 
could hardly be more wrong headed. For example, what is the probability that we 
can make an authoring app that has all the features needed by billions of 
producers?

One conclusion could be that the web/browser is not an app but should be a kind 
of operating system that should be set up to safely execute anything from 
anywhere and to present the results in forms understandable by the end-user.

After literally decades of trying to add more and more features and not yet 
matching up to the software than ran on the machines the original browser was 
done on, they are slowly coming around to the idea that they should be safely 
executing programs written by others. It has only been in the last few years -- 
with Native Client in Chrome -- that really fast programs can be safely 
downloaded as executables without having to have permission of a SysAdmin.

So another way to look at all this is to ask what such an "OS" really needs to 
have to allow all in the world to make their own media and have it used by 
others ...

Cheers,

Alan



>
> From: John Carlson 
>To: Fundamentals of New Computing  
>Sent: Tuesday, February 12, 2013 9:00 PM
>Subject: [fonc] Design of web, POLs for rules. Fuzz testing nile
> 
>
>Although I have read very little about the design of the web, things are 
>starting to gel in my mind.  At the lowest level lies the static or 
>declarative part of the web.  The html, dom, xml and json are the main 
>languages used in the declarative part.  Layered on top of this is the dynamic 
>or procedural part of the web.  Javascript and xslt are the main languages in 
>the procedural part.   The final level is the constraints or rule based part 
>of the web, normally called stylesheets.  The languages in the rule based web 
>are css1, 2, 3 and xsl. Jquery provides a way to apply operations in this 
>arena.  I am excluding popular server side languages...too many.
>What I am wondering is what is the best way to incorporate rules into a 
>language.  Vrml has routes.  Uml has ocl. Is avoiding if statements and 
>for/while loops the goal of rules languages--that syntax?  That is, do a query 
>or find, and apply the operations or rules to all returned values.
>Now, if I wanted to apply probabilistic or fuzzy rules to the dom, that seems 
>fairly straightforward.  Fuzz testing does this moderately well.  Has there 
>been attempts at better fuzz testing? Fuzz about fuzz?  Or is brute force best?
>We've also seen probablistic parser generators, correct?
>But what about probablistic rules?  Can we design an ultimate website w/o a 
>designer?  Can we use statistics to create a great solitaire player--i have a 
>pretty good stochastic solitaire player for one version of solitaire...how 
>about others?  How does one create a great set of rules?  One can create great 
>rule POLs, but where are the authors?  Something like cameron browne's thesis 
>seems great for grid games.  He is quite prolific.  Can we apply the same 
>logic to card games? Web sites?  We have "The Nature of Order" by c. 
>Alexander.  Are there nile designers or fuzz testers/genetic algorithms for 
>nile?
>Is fuzz testing a by product of nile design...should it be?
>If you want to check out the state of the art for dungeons and dragons POLs 
>check out fantasy grounds...xml hell.  We can do better.
>___
>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 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 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.
>> 

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] Paranoid programming language

[David Pennell]

Malboge (http://en.wikipedia.org/wiki/Malbolge) was featured on an episode
of Elementary.  It's named after the eighth circle of hell in Dante's
Inferno.

Malbolge was so difficult to understand when it arrived that it took two
> years for the first Malbolge program to appear. The first Malbolge program
> was not written by a human being, it was generated by a beam 
> searchalgorithm designed by Andrew 
> Cooke and implemented in
> Lisp 
>

-david


On Wed, Feb 13, 2013 at 6:06 AM, Miles Fidelman
wrote:

> Well, for evocative names, there's always Brainfuck (
> http://en.wikipedia.org/wiki/**Brainfuck)
> - which is a real language, with derivatives even.  And the name is truly
> accurate. :-)
>
> John Carlson wrote:
>
>>
>> Ah first time I came across a language with such an evocative name.
>>  Since I am too paranoid to click on a link, perhaps you could summarize. I
>> did a search and it seemed to indicate that the language was a joke.  Sigh.
>>
>> On Feb 12, 2013 7:26 PM, "Miles Fidelman" > mfidelman@**meetinghouse.net >> wrote:
>>
>> 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
>>
>>
>>
>>
>> __**_
>> 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
>
> --
> -david
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Paranoid programming language

[Miles Fidelman]

Well, for evocative names, there's always Brainfuck 
(http://en.wikipedia.org/wiki/Brainfuck) - which is a real language, 
with derivatives even.  And the name is truly accurate. :-)


John Carlson wrote:


Ah first time I came across a language with such an evocative name.  
Since I am too paranoid to click on a link, perhaps you could 
summarize. I did a search and it seemed to indicate that the language 
was a joke.  Sigh.


On Feb 12, 2013 7:26 PM, "Miles Fidelman" > wrote:


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



___
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"

[Thiago Silva]

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 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 progra