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. 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
Re: [fonc] Paranoid programming language
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 mfidel...@meetinghouse.net mailto:mfidel...@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 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] Paranoid programming language
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 searchhttp://en.wikipedia.org/wiki/Beam_searchalgorithm designed by Andrew Cooke and implemented in Lisp http://en.wikipedia.org/wiki/Lisp_programming_language -david On Wed, Feb 13, 2013 at 6:06 AM, Miles Fidelman mfidel...@meetinghouse.netwrote: Well, for evocative names, there's always Brainfuck ( http://en.wikipedia.org/wiki/**Brainfuckhttp://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 mfidel...@meetinghouse.netmailto: mfidelman@**meetinghouse.net mfidel...@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.htmlhttp://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 mailto:fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://vpri.org/mailman/listinfo/fonc __**_ fonc mailing list fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://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] 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
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
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 yottz...@gmail.com To: Fundamentals of New Computing fonc@vpri.org 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
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 with
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 alan.n...@yahoo.com 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 yottz...@gmail.com *To:* Fundamentals of New Computing fonc@vpri.org *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] Design of web, POLs for rules. Fuzz testing nile
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 dphar...@telus.net To: Alan Kay alan.n...@yahoo.com; Fundamentals of New Computing fonc@vpri.org 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 alan.n...@yahoo.com 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 yottz...@gmail.com To: Fundamentals of New Computing fonc@vpri.org 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] Design of web, POLs for rules. Fuzz testing nile
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] 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 of the
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 be
Re: [fonc] [SUSPECTED SPAM] Re: Terminology: Object Oriented vs Message Oriented
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 tsi...@sourcecraft.info 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 this list have pointed this out also. There are similar scaling problems with the use of
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 of
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
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
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
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 mfidel...@meetinghouse.net To: Fundamentals of New Computing fonc@vpri.org 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
[fonc] Building blocks and use of text
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
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
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
On Feb 13, 2013 7:57 PM, Miles Fidelman mfidel...@meetinghouse.net 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
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 mfidel...@meetinghouse.net To: Fundamentals of New Computing fonc@vpri.org 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] Building blocks and use of text
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] Building blocks and use of text
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.netwrote: 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/fonchttp://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Paranoid programming language
That's a good name for a programming language! On Wed, Feb 13, 2013 at 4:20 AM, David Pennell pennell.da...@gmail.comwrote: 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 searchhttp://en.wikipedia.org/wiki/Beam_searchalgorithm designed by Andrew Cooke and implemented in Lisp http://en.wikipedia.org/wiki/Lisp_programming_language -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/**Brainfuckhttp://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 mfidel...@meetinghouse.netmailto: mfidelman@**meetinghouse.net mfidel...@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.htmlhttp://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 mailto:fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://vpri.org/mailman/listinfo/fonc __**_ fonc mailing list fonc@vpri.org http://vpri.org/mailman/**listinfo/fonchttp://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 http://vpri.org/mailman/listinfo/fonc ___ 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
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 yottz...@gmail.com 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/fonchttp://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
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/ /fanboy On Wed, Feb 13, 2013 at 5:55 PM, John Carlson yottz...@gmail.com 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
