Re: [fonc] Terminology: Object Oriented vs Message Oriented
From: Jeff Gonis jeff.go...@gmail.commailto:jeff.go...@gmail.com To: Alan Kay alan.n...@yahoo.commailto:alan.n...@yahoo.com Cc: Fundamentals of New Computing fonc@vpri.orgmailto:fonc@vpri.org Sent: Tuesday, February 12, 2013 10:33 AM Subject: Re: [fonc] Terminology: Object Oriented vs Message Oriented I see no one has taken Alan's bait and asked the million dollar question: if you decided that messaging is no longer the right path for scaling, what approach are you currently using? From my last trip to the SPLASH conference a few years ago, I've been contemplating a lot of these ideas. Especially the messaging paradigm and the current conundrum with concurrency and scaling. A common theme (brought up by Ivan Sutherland paraphrased here) is that in the past processing was expensive, now its communication. From the sheer amount of development code and processing done to pack up data in an understandable form, serialize it, encrypt it, etc so it can get to another component to process (at least at the macro distributed systems level). Now it's a concern with the multi-core processors that need to process data. I went to some of the workshops on the functional languages and Actors as a way to handle some of these issues through asynchronous messaging. My thought, but I've not found much work in this area is in this era of virtualization, a small program or service can be instantiated anywhere as long as location independence is honored. So why not do a lot of the distributed work by instantiating these services to where a majority of the data is located. Sure there will be times when it needs to be shipped somewhere, but most of the communication needed would be smaller control data to coordinate the program instantiations and handoff (Like some of the IPC work I used to do with unix processes using semaphores). The most significant con I see to this is handling fault tolerance so there are no deadlocks. I realize there are much more experienced smart people on this forum that could shoot some holes in this approach, and I invite you to do so. My feeling won't be hurt as long as I can learn some more. Most of my experience is in the boring arena of Business IT (with my earlier years in Defense with Simulators and Communication Systems). Thanks for any reply, John Brown From: Alan Kay alan.n...@yahoo.commailto:alan.n...@yahoo.com Reply-To: Alan Kay alan.n...@yahoo.commailto:alan.n...@yahoo.com, Fundamentals of New Computing fonc@vpri.orgmailto:fonc@vpri.org Date: Wed, 13 Feb 2013 18:51:59 -0500 To: Fundamentals of New Computing fonc@vpri.orgmailto:fonc@vpri.org Subject: [SUSPECTED SPAM] Re: [fonc] Terminology: Object Oriented vs Message Oriented Hi Barry I like your characterization, and do think the next level also will require a qualitatively different approach Cheers, Alan From: Barry Jay barry@uts.edu.aumailto:barry@uts.edu.au To: fonc@vpri.orgmailto: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
Re: [fonc] Terminology: Object Oriented vs Message Oriented
print out the bit bin. This was known as PostScript when it came out in the world. The Trickles idea from Cornell has much of the same flavor. One possible starting place is to notice that there are lots more terms that people can use than the few that are needed to make a powerful compact programming language. So why not try to describe meanings and match on meanings -- and let there be not just matching (which is like a password) but negotiation, which is what a discovery agent does. And so forth. I think this is a difficult but doable problem -- it's easier than AI, but has some tinges of it. Got any ideas? Cheers, Alan From: Jeff Gonis jeff.go...@gmail.com To: Alan Kay alan.n...@yahoo.com Cc: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, February 12, 2013 10:33 AM Subject: Re: [fonc] Terminology: Object Oriented vs Message Oriented I see no one has taken Alan's bait and asked the million dollar question: if you decided that messaging is no longer the right path for scaling, what approach are you currently using? I would assume that FONC is the current approach, meaning, at the risk of grossly over-simplifying and sounding ignorant, problem oriented languages allowing for compact expression of meaning. But even here, FONC struck me as providing vastly better ways of creating code that, at its core, still used messaging for robustness, etc, rather than using something entirely different. Have I completely misread the FONC projects? And if not messaging, what approach are you currently using to handle scalability? A little more history ... The first Smalltalk (-72) was modern (as used below), and similar to Erlang in several ways -- for example, messages were received with structure and pattern matching, etc. The language was extended using the same mechanisms ... Cheers, Alan From: Brian Rice briantr...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, February 12, 2013 8:54 AM Subject: Re: [fonc] Terminology: Object Oriented vs Message Oriented Independently of the originally-directed historical intent, I'll pose my own quick perspective. Perhaps a contrast with Steve Yegge's Kingdom of Nouns essay would help: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html The modern post-Erlang sense of message-oriented computing has to do with messages with structure and pattern-matching, where error-handling isn't about sequential, nested access, but more about independent structures dealing with untrusted noise. Anyway, treating the messages as first-class objects (in the Lisp sense) is what gets you there: http://www.erlang.org/doc/getting_started/conc_prog.html On Tue, Feb 12, 2013 at 7:15 AM, Loup Vaillant l...@loup-vaillant.fr wrote: This question was prompted by a quote by Joe Armstrong about OOP[1]. It is for Alan Kay, but I'm totally fine with a relevant link. Also, I don't know and I don't have time for this are perfectly okay. Alan, when the term Object oriented you coined has been hijacked by Java and Co, you made clear that you were mainly about messages, not classes. My model of you even says that Erlang is far more OO than Java. Then why did you chose the term object instead of message in the first place? Was there a specific reason for your preference, or did you simply not bother foreseeing any terminology issue? (20/20 hindsight and such.) Bonus question: if you had choose message instead, do you think it would have been hijacked too? Thanks, Loup. [1]: http://news.ycombinator.com/item?id=5205976 (This is for reference, you don't really need to read it.) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- -Brian T. Rice ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- []'s Thiago Silva http://www.metareload.com We are either doing something or we are not; 'talking about' is a subset of 'not'. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Terminology: Object Oriented vs Message Oriented
On Tue, Feb 12, 2013 at 11:33:04AM -0700, Jeff Gonis wrote: I see no one has taken Alan's bait and asked the million dollar question: if you decided that messaging is no longer the right path for scaling, what approach are you currently using? Classical computation doesn't allow storing multiple bits in the same location, so relativistic signalling introduces latency. Asynchronous shared-nothing message passing is the only thing that scales, as it matches the way how this universe does things (try looking at light cones for consistent state for multiple writes to the same location -- this of course applies to cache coherency). Inversely, doing things in a different way will guarantee that you won't be able to scale. It's not just a good idea, it's the law. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Terminology: Object Oriented vs Message Oriented
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 eu...@leitl.org To: Fundamentals of New Computing fonc@vpri.org 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
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 tsi...@sourcecraft.info To: fonc fonc@vpri.org Sent: Wednesday, February 13, 2013 2:09 AM Subject: Re: [fonc] Terminology: Object Oriented vs Message Oriented Hello, as I was thinking over these problems today, here are some initial thoughts, just to get the conversation going... The first time I read about the Method Finder and Ted's memo, I tried to grasp the broader issue, and I'm still thinking of some interesting examples to explore. I can see the problem of finding operations by their meanings, the problem of finding objects by the services they provide and the overal structure of the discovery, negotiation and binding. My feeling is that, besides using worlds as mechanism, an explicit discovery context may be required (though I can't say much without further experimentations), specially when trying to figure out operations that don't produce a distinguishable value but rather 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
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 alan.n...@yahoo.com 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 tsi...@sourcecraft.info *To:* fonc fonc@vpri.org *Sent:* Wednesday, February 13, 2013 2:09 AM *Subject:* Re: [fonc] Terminology: Object Oriented vs Message Oriented Hello, as I was thinking over these problems today, here are some initial thoughts, just to get the conversation going... The first time I read about the Method Finder and Ted's memo, I tried to grasp the broader issue, and I'm still thinking of some interesting examples to explore. I can see the problem of finding operations by their meanings, the problem of finding objects by the services they provide and the overal structure of the discovery, negotiation and binding. My feeling is that, besides using worlds as mechanism, an explicit discovery context may be required (though I can't say much without further experimentations), specially when trying to figure out operations that don't produce a distinguishable value but rather 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
Re: [fonc] Terminology: Object Oriented vs Message Oriented
I was imagining QuickCheck properties instead of unit tests... On Wed, Feb 13, 2013 at 10:40 AM, Alan Kay alan.n...@yahoo.com wrote: Unit tests are just a small part of the kinds of description that could be used and are needed. From: David Harris dphar...@telus.net To: Alan Kay alan.n...@yahoo.com; Fundamentals of New Computing fonc@vpri.org 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 alan.n...@yahoo.com 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 tsi...@sourcecraft.info To: fonc fonc@vpri.org Sent: Wednesday, February 13, 2013 2:09 AM Subject: Re: [fonc] Terminology: Object Oriented vs Message Oriented Hello, as I was thinking over these problems today, here are some initial thoughts, just to get the conversation going... The first time I read about the Method Finder and Ted's memo, I tried to grasp the broader issue, and I'm still thinking of some interesting examples to explore. I can see the problem of finding operations by their meanings, the problem of finding objects by the services they provide and the overal structure of the discovery, negotiation and binding. My feeling is that, besides using worlds as mechanism, an explicit discovery context may be required (though I can't say much without further experimentations), specially when trying to figure out operations that don't produce a distinguishable value but rather 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
Re: [fonc] Terminology: Object Oriented vs Message Oriented
If doing experiment means experimenting with meaning, I agree. On Feb 13, 2013 3:17 PM, Barry Jay barry@uts.edu.au wrote: ** Hi Alan, the phrase I picked up on was doing experiments. One way to think of the problem is that we are trying to automate the scientific process, which is a blend of reasoning and experiments. Most of us focus on one or the other, as in deductive AI versus databases of common knowledge, but the history of physics etc suggests that we need to develop both within a single system, e.g. a language that supports both higher-order programming (for strategies, etc) and generic queries (for conducting experiments on newly met systems). Yours, Barry On 02/14/2013 02:26 AM, Alan Kay wrote: Hi Thiago I think you are on a good path. One way to think about this problem is that the broker is a human programmer who has received a module from half way around the world that claims to provide important services. The programmer would confine it in an address space and start doing experiments with it to try to discover what it does (and/or perhaps how well its behavior matches up to its claims). Many of the discovery approaches of Lenat in AM and Eurisko could be very useful here. Another part of the scaling of modules approach could be to require modules to have much better models of the environments they expect/need in order to run. For example, suppose a module has a variable that it would like to refer to some external resource. Both static and dynamic typing are insufficient here because they are only about kinds of results rather than meanings of results. But we could readily imagine a language in which the variable had associated with it a dummy or stand-in model of what is desired. It could be a slow version of something we are hoping to get a faster version of. It could be sample values and tests, etc. All of these would be useful for debugging our module -- in fact, we could make this a requirement of our module system, that the modules carry enough information to allow them to be debugged with only their own model of the environment. And the more information the model has, the easier it will be for a program to see if the model of an environment for a module matches up to possible modules out in the environment when the system is running for real. Cheers, Alan -- *From:* Thiago Silva tsi...@sourcecraft.info tsi...@sourcecraft.info *To:* fonc fonc@vpri.org fonc@vpri.org *Sent:* Wednesday, February 13, 2013 2:09 AM *Subject:* Re: [fonc] Terminology: Object Oriented vs Message Oriented Hello, as I was thinking over these problems today, here are some initial thoughts, just to get the conversation going... The first time I read about the Method Finder and Ted's memo, I tried to grasp the broader issue, and I'm still thinking of some interesting examples to explore. I can see the problem of finding operations by their meanings, the problem of finding objects by the services they provide and the overal structure of the discovery, negotiation and binding. My feeling is that, besides using worlds as mechanism, an explicit discovery context may be required (though I can't say much without further experimentations), specially when trying to figure out operations that don't produce a distinguishable value but rather 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
Re: [fonc] Terminology: Object Oriented vs Message Oriented
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 barry@uts.edu.au mailto:barry@uts.edu.au wrote: Hi Alan, the phrase I picked up on was doing experiments. One way to think of the problem is that we are trying to automate the scientific process, which is a blend of reasoning and experiments. Most of us focus on one or the other, as in deductive AI versus databases of common knowledge, but the history of physics etc suggests that we need to develop both within a single system, e.g. a language that supports both higher-order programming (for strategies, etc) and generic queries (for conducting experiments on newly met systems). Yours, Barry On 02/14/2013 02:26 AM, Alan Kay wrote: Hi Thiago I think you are on a good path. One way to think about this problem is that the broker is a human programmer who has received a module from half way around the world that claims to provide important services. The programmer would confine it in an address space and start doing experiments with it to try to discover what it does (and/or perhaps how well its behavior matches up to its claims). Many of the discovery approaches of Lenat in AM and Eurisko could be very useful here. Another part of the scaling of modules approach could be to require modules to have much better models of the environments they expect/need in order to run. For example, suppose a module has a variable that it would like to refer to some external resource. Both static and dynamic typing are insufficient here because they are only about kinds of results rather than meanings of results. But we could readily imagine a language in which the variable had associated with it a dummy or stand-in model of what is desired. It could be a slow version of something we are hoping to get a faster version of. It could be sample values and tests, etc. All of these would be useful for debugging our module -- in fact, we could make this a requirement of our module system, that the modules carry enough information to allow them to be debugged with only their own model of the environment. And the more information the model has, the easier it will be for a program to see if the model of an environment for a module matches up to possible modules out in the environment when the system is running for real. Cheers, Alan *From:* Thiago Silva tsi...@sourcecraft.info mailto:tsi...@sourcecraft.info *To:* fonc fonc@vpri.org mailto:fonc@vpri.org *Sent:* Wednesday, February 13, 2013 2:09 AM *Subject:* Re: [fonc] Terminology: Object Oriented vs Message Oriented Hello, as I was thinking over these problems today, here are some initial thoughts, just to get the conversation going... The first time I read about the Method Finder and Ted's memo, I tried to grasp the broader issue, and I'm still thinking of some interesting examples to explore. I can see the problem of finding operations by their meanings, the problem of finding objects by the services they provide and the overal structure of the discovery, negotiation and binding. My feeling is that, besides using worlds as mechanism, an explicit discovery context may be required (though I can't say much without further experimentations), specially when trying to figure out operations that don't produce a distinguishable value but rather 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
Re: [fonc] Terminology: Object Oriented vs Message Oriented
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 barry@uts.edu.au 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 barry@uts.edu.au wrote: Hi Alan, the phrase I picked up on was doing experiments. One way to think of the problem is that we are trying to automate the scientific process, which is a blend of reasoning and experiments. Most of us focus on one or the other, as in deductive AI versus databases of common knowledge, but the history of physics etc suggests that we need to develop both within a single system, e.g. a language that supports both higher-order programming (for strategies, etc) and generic queries (for conducting experiments on newly met systems). Yours, Barry On 02/14/2013 02:26 AM, Alan Kay wrote: Hi Thiago I think you are on a good path. One way to think about this problem is that the broker is a human programmer who has received a module from half way around the world that claims to provide important services. The programmer would confine it in an address space and start doing experiments with it to try to discover what it does (and/or perhaps how well its behavior matches up to its claims). Many of the discovery approaches of Lenat in AM and Eurisko could be very useful here. Another part of the scaling of modules approach could be to require modules to have much better models of the environments they expect/need in order to run. For example, suppose a module has a variable that it would like to refer to some external resource. Both static and dynamic typing are insufficient here because they are only about kinds of results rather than meanings of results. But we could readily imagine a language in which the variable had associated with it a dummy or stand-in model of what is desired. It could be a slow version of something we are hoping to get a faster version of. It could be sample values and tests, etc. All of these would be useful for debugging our module -- in fact, we could make this a requirement of our module system, that the modules carry enough information to allow them to be debugged with only their own model of the environment. And the more information the model has, the easier it will be for a program to see if the model of an environment for a module matches up to possible modules out in the environment when the system is running for real. Cheers, Alan -- *From:* Thiago Silva tsi...@sourcecraft.info tsi...@sourcecraft.info *To:* fonc fonc@vpri.org fonc@vpri.org *Sent:* Wednesday, February 13, 2013 2:09 AM *Subject:* Re: [fonc] Terminology: Object Oriented vs Message Oriented Hello, as I was thinking over these problems today, here are some initial thoughts, just to get the conversation going... The first time I read about the Method Finder and Ted's memo, I tried to grasp the broader issue, and I'm still thinking of some interesting examples to explore. I can see the problem of finding operations by their meanings, the problem of finding objects by the services they provide and the overal structure of the discovery, negotiation and binding. My feeling is that, besides using worlds as mechanism, an explicit discovery context may be required (though I can't say much without further experimentations), specially when trying to figure out operations that don't produce a distinguishable value but rather 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
Re: [fonc] Terminology: Object Oriented vs Message Oriented
Hi Barry I like your characterization, and do think the next level also will require a qualitatively different approach Cheers, Alan From: Barry Jay barry@uts.edu.au 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 tsi...@sourcecraft.info To: fonc fonc@vpri.org Sent: Wednesday, February 13, 2013 2:09 AM Subject: Re: [fonc] Terminology: Object Oriented vs Message Oriented Hello, as I was thinking over these problems today, here are some initial thoughts, just to get the conversation going... The first time I read about the Method Finder and Ted's memo, I tried to grasp the broader issue, and I'm still thinking of some interesting examples to explore. I can see the problem of finding operations by their meanings, the problem of finding objects by the services they provide and the overal structure of the discovery, negotiation and binding. My feeling is that, besides using worlds as mechanism, an explicit discovery context may be required (though I can't say much without further experimentations), specially when trying to figure out operations that don't produce a distinguishable value but rather 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
[fonc] Terminology: Object Oriented vs Message Oriented
This question was prompted by a quote by Joe Armstrong about OOP[1]. It is for Alan Kay, but I'm totally fine with a relevant link. Also, I don't know and I don't have time for this are perfectly okay. Alan, when the term Object oriented you coined has been hijacked by Java and Co, you made clear that you were mainly about messages, not classes. My model of you even says that Erlang is far more OO than Java. Then why did you chose the term object instead of message in the first place? Was there a specific reason for your preference, or did you simply not bother foreseeing any terminology issue? (20/20 hindsight and such.) Bonus question: if you had choose message instead, do you think it would have been hijacked too? Thanks, Loup. [1]: http://news.ycombinator.com/item?id=5205976 (This is for reference, you don't really need to read it.) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Terminology: Object Oriented vs Message Oriented
.) This is part of the big problem in OOP today, because it is mostly a complicated way of making new data structures whose fields are munged by setters. Back to your original question, it *might* have helped to have better terminology. The Simula folks tried this in the first Simula, but their choice of English words was confusing (they used Activity for Class and Process for Instance). This is almost good and much more in keeping with what should be the philosophical underpinnings of this kind of design. After being told that no one had understood this (I and two other grad students had to read the machine code listing of the Simula compiler to understand its documentation!), the Nygaard and Dahl chose Class and Instance for Simula 67. I chose these for Smalltalk also because why multiply terms? (I should have chosen better terms here also.) To sum up, besides the tiny computers we had to use back then, we didn't have a good enough theory of messaging -- we did have a start that was based on Dave Fisher's Control Definition Language CMU 1970 thesis. But then we got overwhelmed by the excitement of being able to make personal computing on the Alto. A few years later I decided that sending messages was not a good scaling idea, and that something more general to get needed resources from the outside needed to be invented. Cheers, Alan From: Loup Vaillant l...@loup-vaillant.fr To: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, February 12, 2013 7:15 AM Subject: [fonc] Terminology: Object Oriented vs Message Oriented This question was prompted by a quote by Joe Armstrong about OOP[1]. It is for Alan Kay, but I'm totally fine with a relevant link. Also, I don't know and I don't have time for this are perfectly okay. Alan, when the term Object oriented you coined has been hijacked by Java and Co, you made clear that you were mainly about messages, not classes. My model of you even says that Erlang is far more OO than Java. Then why did you chose the term object instead of message in the first place? Was there a specific reason for your preference, or did you simply not bother foreseeing any terminology issue? (20/20 hindsight and such.) Bonus question: if you had choose message instead, do you think it would have been hijacked too? Thanks, Loup. [1]: http://news.ycombinator.com/item?id=5205976 (This is for reference, you don't really need to read it.) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Terminology: Object Oriented vs Message Oriented
Dude…. You said shiny objects….Lol. Messaging certainly seems to have a larger focus with multi-core, many-core, and cloud computing concepts (that itself is morphing into shiny objects). I also enjoy these history lessons and discussions. John From: David Hussman david.huss...@devjam.commailto:david.huss...@devjam.com Reply-To: Fundamentals of New Computing fonc@vpri.orgmailto:fonc@vpri.org Date: Tue, 12 Feb 2013 11:36:35 -0500 To: 'Alan Kay' alan.n...@yahoo.commailto:alan.n...@yahoo.com, 'Fundamentals of New Computing' fonc@vpri.orgmailto:fonc@vpri.org Subject: Re: [fonc] Terminology: Object Oriented vs Message Oriented Alan, Thanks for the thoughtful words / history. I am a lurker on this group and I dig seeing this kind of dialog during times when I am so often surrounded by bright shiny object types. David From: fonc-boun...@vpri.orgmailto:fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of Alan Kay Sent: Tuesday, February 12, 2013 10:23 AM To: Fundamentals of New Computing Subject: Re: [fonc] Terminology: Object Oriented vs Message Oriented Hi Loup I think how this happened has already been described in The Early History of Smalltalk. But In the Fall of 1966, Sketchpad was what got me started thinking about representing concepts as whole things. Simula, a week later, provided a glimpse of how one could deal with issues that couldn't be done wonderfully with constraints and solving (namely, you could hide procedures inside the entities). This triggered off many thoughts in a few minutes, bringing in ideas that seemed similar from biology, math (algebras), logic (Carnap's intensional logic), philosophy (Plato's Ideas), hardware (running multiple active units off a bus), systems design (the use of virtual machines in time-sharing), and networking (the ARPA community was getting ready to do the ARPAnet). Bob Barton had pronounced that recursive design is making the parts have the same powers as the wholes, which for the first time I was able to see was really powerful if the wholes and the parts were entire computers hardware or software or some mixture. The latter was hugely important to me because it allowed a universal simulation system to be created from just a few ideas that would cover everything and every other kind of thing. During this period I had no label for what I was doing, including this thing I was doing, I was just doing. A few months later someone asked me what I was doing, and I didn't think about the answer -- I was still trying to see how the synthesis of ideas could be pulled off without a lot of machinery (kind of the math stage of the process). Back then, there was already a term in use called data driven programming. This is where data contains info that will help find appropriate procedures. And the term objects was also used for composite data i.e. blocks of storage with different fields containing values of various kinds. This came naturally from card images (punched cards were usually 80 or more characters long and divided into fields). At some point someone (probably in the 50s) decided to use some of the fields to help the logic of plug board programming and drive the processes off the cards rather than just processing them. So if you looked at how Sketchpad was implemented you would see, in the terms of the day: objects that were data driven. Ivan gives Doug Ross credit for his plex structures, which were an MIT way to think about these ideas. Sketchpad also used threaded lists in its blocks (this was not a great idea but it was popular back then -- Simula later took this up as well). So I just said object oriented programming and went back to work. Later I regretted this (and some of the other labels that were also put in service) after the ideas worked out nicely and were very powerful for us at PARC. The success of the ideas made what we were doing popular, and people wanted to be a part of it. This led to using the term object oriented as a designer jeans label for pretty much anything (there was even an object-oriented COBOL!). This appropriation of labels without content is a typical pop culture fantasy football syndrome. PARC was an integral part of the ARPA community, the last gasp of which in the 70s was designing the Internet via a design group that contained PARC people (PARC had actually already done an internetwork -- called PUP -- with gateways (routers) to interconnect Ethernetworks and other networks within Xerox). It was clear to all in this community from the mid-60s onward that how messaging was done was one of the keys to achieving scaling. This is why what I was working on had messages as the larger coordination idea (rather than the subset of calls). At PARC we wanted to do a complete personal computing system on the Alto, which was a microcoded ~150ns cycle CPU with 16 program counters and 64k 16bit words of memory that cycled at ~750ns (where half
Re: [fonc] Terminology: Object Oriented vs Message Oriented
Alan Kay a écrit : Hi Loup I think how this happened has already been described in The Early History of Smalltalk. But [Incredibly detailed and thoughtful response] Whoa. Thank you. Loup ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Terminology: Object Oriented vs Message Oriented
Hi! On 02/12/2013 04:15 PM, Loup Vaillant wrote: This question was prompted by a quote by Joe Armstrong about OOP[1]. Sidenote, the article Joe wrote on OO which I subsequently bashed: http://goran.krampe.se/2009/06/26/joe-is-wrong/ ...but I met him later and he knows OO quite well these days - and is also friends with several of our luminaries. regards, Göran ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Terminology: Object Oriented vs Message Oriented
Alan Kay wrote: A little more history ... The first Smalltalk (-72) was modern (as used below), and similar to Erlang in several ways -- for example, messages were received with structure and pattern matching, etc. The language was extended using the same mechanisms ... Alan, As I recall, some of your early writings on Smalltalk sounded very actor-like - i.e., objects as processes, with lots of messages floating around, rather than a sequential thread-of-control model. Or is my memory just getting fuzzy? In any case, I'm surprised that the term actor hasn't popped up in this thread, along with object and messaging. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Terminology: Object Oriented vs Message Oriented
Hi Jeff I think intermodule communication schemes that *really scale* is one of the most important open issues of the last 45 years or so. It is one of the several pursuits written into the STEPS proposal that we didn't use our initial efforts on -- so we've done little to advance this over the last few years. But now that the NSF funded part of STEPS has concluded, we are planning to use much of the other strand of STEPS to look at some of these neglected issues. There are lots of facets, and one has to do with messaging. The idea that sending a message has scaling problems is one that has been around for quite a while. It was certainly something that we pondered at PARC 35 years ago, and it was an issue earlier for both the ARPAnet and its offspring: the Internet. Several members of this list have pointed this out also. There are similar scaling problems with the use of tags in XML and EMI etc. which have to be agreed on somehow Part of the problem is that for vanilla sends, the sender has to know the receiver in some fashion. This starts requiring the interior of a module to know too much if this is a front line mechanism. This leads to wanting to do something more like LINDA coordination or publish and subscribe where there are pools of producers and consumers who don't have to know explicitly about each other. A send is now a general request for a resource. But the vanilla approaches here still require that the sender and receiver have a fair amount of common knowledge (because the matching is usually done on terms in common). For example, in order to invoke a module that will compute the sine of an angle, do you and the receiver both have to agree about the term sine? In APL I think the name of this function is circle 1 and in Smalltalk it's degreeSin, etc. Ted Kaehler solved this problem some years ago in Squeak Smalltalk with his message finder. For example, if you enter 3. 4. 7 Squeak will instantly come back with: 3 bitOr: 4 -- 7 3 bitXor: 4 -- 7 3 + 4 -- 7 For the sine example you would enter 30. 0.5 and Squeak will come up with: 30 degreeSin -- 0.5 The method finder is acting a bit like Doug Lenat's discovery systems. Simple brute force is used here (Ted executes all the methods that could fit in the system safely to see what they do.) One of the solutions at PARC for dealing with a part of the problem is the idea of send an agent, not a message. It was quickly found that defining file formats for all the different things that could be printed on the new laser printer was not scaling well. The solution was to send a program that would just execute safely and blindly in the printer -- the printer would then just print out the bit bin. This was known as PostScript when it came out in the world. The Trickles idea from Cornell has much of the same flavor. One possible starting place is to notice that there are lots more terms that people can use than the few that are needed to make a powerful compact programming language. So why not try to describe meanings and match on meanings -- and let there be not just matching (which is like a password) but negotiation, which is what a discovery agent does. And so forth. I think this is a difficult but doable problem -- it's easier than AI, but has some tinges of it. Got any ideas? Cheers, Alan From: Jeff Gonis jeff.go...@gmail.com To: Alan Kay alan.n...@yahoo.com Cc: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, February 12, 2013 10:33 AM Subject: Re: [fonc] Terminology: Object Oriented vs Message Oriented I see no one has taken Alan's bait and asked the million dollar question: if you decided that messaging is no longer the right path for scaling, what approach are you currently using? I would assume that FONC is the current approach, meaning, at the risk of grossly over-simplifying and sounding ignorant, problem oriented languages allowing for compact expression of meaning. But even here, FONC struck me as providing vastly better ways of creating code that, at its core, still used messaging for robustness, etc, rather than using something entirely different. Have I completely misread the FONC projects? And if not messaging, what approach are you currently using to handle scalability? A little more history ... The first Smalltalk (-72) was modern (as used below), and similar to Erlang in several ways -- for example, messages were received with structure and pattern matching, etc. The language was extended using the same mechanisms ... Cheers, Alan From: Brian Rice briantr...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, February 12, 2013 8:54 AM Subject: Re: [fonc] Terminology: Object Oriented vs Message Oriented Independently of the originally-directed historical intent, I'll pose my own quick perspective. Perhaps a contrast with Steve Yegge's
Re: [fonc] Terminology: Object Oriented vs Message Oriented
Hi Miles (Again The Early History of Smalltalk has some of this history ...) It is unfair to Carl Hewitt to say that Actors were his reaction to Smalltalk-72 (because he had been thinking early thoughts from other influences). And I had been doing a lot of thinking about the import of his Planner language. But that is the simplest way of stating the facts and the ordering. ST-72 and the early Actors follow on were very similar. The Smalltalk that didn't get made, -71, was a kind of merge of the object idea, Logo, and Carl's Planner system (which predated Prolog and was in many respects more powerful). Planner used pattern-directed invocation and I thought you could both receive messages with it if it were made the interface of an object, and also use it for deduction. Smalltalk-72 was a bit of an accident The divergence later was that we got a bit dirtier as we made a real system that you could program a real system in. Actors got cleaner as they looked at many interesting theoretical possibilities for distributed computing etc. My notion of object oriented would now seem to be very actor-like. Cheers, Alan From: Miles Fidelman mfidel...@meetinghouse.net To: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, February 12, 2013 11:05 AM Subject: Re: [fonc] Terminology: Object Oriented vs Message Oriented Alan Kay wrote: A little more history ... The first Smalltalk (-72) was modern (as used below), and similar to Erlang in several ways -- for example, messages were received with structure and pattern matching, etc. The language was extended using the same mechanisms ... Alan, As I recall, some of your early writings on Smalltalk sounded very actor-like - i.e., objects as processes, with lots of messages floating around, rather than a sequential thread-of-control model. Or is my memory just getting fuzzy? In any case, I'm surprised that the term actor hasn't popped up in this thread, along with object and messaging. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Terminology: Object Oriented vs Message Oriented
Hi Alan, Is it fair to say that the path you took with Smalltalk led to today's object model of data structures, associated methods, and inheritance, with either a single thread-of-control, or small numbers of threads; while the Actor model led (perhaps not directly) to massive concurrency and Erlang? (I'm still waiting for something that looks like Smalltalk meets Erlang.) Cheers, Miles Alan Kay wrote: Hi Miles (Again The Early History of Smalltalk has some of this history ...) It is unfair to Carl Hewitt to say that Actors were his reaction to Smalltalk-72 (because he had been thinking early thoughts from other influences). And I had been doing a lot of thinking about the import of his Planner language. But that is the simplest way of stating the facts and the ordering. ST-72 and the early Actors follow on were very similar. The Smalltalk that didn't get made, -71, was a kind of merge of the object idea, Logo, and Carl's Planner system (which predated Prolog and was in many respects more powerful). Planner used pattern-directed invocation and I thought you could both receive messages with it if it were made the interface of an object, and also use it for deduction. Smalltalk-72 was a bit of an accident The divergence later was that we got a bit dirtier as we made a real system that you could program a real system in. Actors got cleaner as they looked at many interesting theoretical possibilities for distributed computing etc. My notion of object oriented would now seem to be very actor-like. Cheers, Alan *From:* Miles Fidelman mfidel...@meetinghouse.net *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Tuesday, February 12, 2013 11:05 AM *Subject:* Re: [fonc] Terminology: Object Oriented vs Message Oriented Alan Kay wrote: A little more history ... The first Smalltalk (-72) was modern (as used below), and similar to Erlang in several ways -- for example, messages were received with structure and pattern matching, etc. The language was extended using the same mechanisms ... Alan, As I recall, some of your early writings on Smalltalk sounded very actor-like - i.e., objects as processes, with lots of messages floating around, rather than a sequential thread-of-control model. Or is my memory just getting fuzzy? In any case, I'm surprised that the term actor hasn't popped up in this thread, along with object and messaging. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org mailto:fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Terminology: Object Oriented vs Message Oriented
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
