5 ms·

> The more interesting/optimized ways to map this would be where a single object in the software internet somehow maps to multiple computers ... Yes, this is t

> The more interesting/optimized ways to map this would be where a single object in the software internet somehow maps to multiple computers ... Yes, this is the essence of Dave Reed's 1978 MIT thesis on the design of a distributed OS for the Internet of "consistent" objects mapped to multiple computers. In the early 2000s we had the opportunity to test this design by implementing it. This led to a series of systems called "Croquet" and an open source system and foundation called "Open Cobalt". > how to build semantic models that are optimized for human comprehension of a problem, but can be directly run on farms of physical computers? Keep on with this ...

shalabhc 9y ago
> Keep on with this ... This is still kind of a mishmash of early thoughts and I have a couple of different lines of thought, which I hope will come together. I'll start with a couple of observations: 1. Most programming languages and DSLs are uni-directional - the computer doesn't talk back to the human in the same language. 2. The mental models (not the language) humans use to communicate to each other, even when using a lot of rigor and few ambiguities, is often different than the languages and models used for computation. The first idea is: there are some repeating structures in mental models. We think new concepts in terms of old by first thinking the structures (which are few and axiomatic, like the structure/function words in English) and then materializing the content, as well as refining the structures. E.g. I can say to a non-programmer that 'classes contain methods' and they kind of get the structure without knowing the content. In my mind this is represented as a graph, where the 'contains' relationship is an edge that connects two 'content nodes'. [something called class] --(contains)-> [something called method] If I follow up with 'methods contain code', they can reason that classes indirectly contain code, without even knowing what these things actually mean! So 'contains' is kind of a universal concept - it applies to abstract content and physical content in a similar way. Another universal connection is 'abstraction of', this implies one node (the abstract thing) is related to other nodes (the concrete things) in a specific way. Maybe structures can be made composable, and we can operate on graphs structurally, without knowing what the content means? While another operation might eventually figure out what the content means. The main assumption here is my thoughts are organized as graphs, where connections are both universal also domain specific but of few kinds. Can I talk to the computer in terms of such graphs? The second idea is: I want to combine high level concepts and strategies from from somewhat different domains. E.g. if I know different strategies for 'distributing things into bins' (consistent hashing, sharding, etc.), I invoke this 'idea' manually whenever I have see a situation which looks like 'distribute things into bins' and make a choice - irrespective of scale. Can I get the computer to do this for me instead? So the final thing here is to get to something like this: I take an idea (i.e. a node in a graph) from the distributed computing domain, merge it with a definition (another node) of a computation I created (e.g. persistence strategies), and have the computer offer options on how to distribute that computation (i.e. 'distributed persistence strategies'). Then I can make choices and combine it with a 'convert idea to machine code' strategy and generate a program. This is all a bit abstract at this point, but I'm also trying to find where this overlaps with prior art.
- scroot 9y ago
  > The main assumption here is my thoughts are organized as graphs Herbert Simon talks a lot about this in Sciences of the Artificial. It turns out most of human thinking is just lists. I'm not sure if that still stands in the field of psychology (my version of the book is pretty old, from the 80s). There's a good book (a little dense though) that might help with the more abstract thinking in the direction you're going. It's called "Human Machine Reconfigurations" and it's one of the more clever books I've come across on human machine interaction, written by an anthropologist/sociologist who also worked at PARC. So often the human part is what gets lost here.
  - shalabhc 9y ago
    Thanks for the references! Sciences of the Artificial is already on my list. > The main assumption here is my thoughts are organized as graphs I realize this would be better phrased as "the information I'm trying to communicate is organized as graphs'.
- alankay1 9y ago
  A clarifying comment here. When one thinks in terms of what I called objects ca 1966, one is talking about entities that from the outside are identical to what we think of as computers (and this means not just sending messages and getting outputs, but that we don't get to look inside with our messages, and our messages don't get to command, unless whatever is going on in the interior of the computer has decided to allow. So from the outside, there are no imperatives, only requests and questions. Another way to look at this is that an object/computer is a kind of "server" (I worry to use this term because it also has "pop" meanings, but it's a good term.) This is sometimes called "total encapsulation". From this standpoint, we don't know what's inside. Could be just hardware. Could be variables and methods. Could be some form of ontology. Or mix and match. This is the meaning of computers on a network, especially large worldwide ones. The basic idea of "objects" is that what is absolutely needed for doing things at large scale, can be supplied in non-complex terms for also doing the small scale things that used to be done with data structures and procedures. Secondarily, some of the problems of data structures and procedures at any scale can be done away with by going to the "universal servers in systems" ideas. Similarly, what we have to do for critical "data structures" -- such as large scalings, "atomic transactions", versions, redundancy, distribution, backup, and "procedural fields" (such as the attribute "age") are all more easily and cleanly dealt with using the idea of "objects". One of the ways of looking at what happened in programming is that many if not most of the naive ways to deal with things when computers were really small did not scale up, but most programmers wanted to stay with the original methods, and they taught next gen programmers the original methods, and created large fragile bodies of legacy code that requires experts in the old methods to maintain, fix, extend ...

shalabhc 9y ago

> Keep on with this ... This is still kind of a mishmash of early thoughts and I have a couple of different lines of thought, which I hope will come together. I'll start with a couple of observations: 1. Most programming languages and DSLs are uni-directional - the computer doesn't talk back to the human in the same language. 2. The mental models (not the language) humans use to communicate to each other, even when using a lot of rigor and few ambiguities, is often different than the languages and models used for computation. The first idea is: there are some repeating structures in mental models. We think new concepts in terms of old by first thinking the structures (which are few and axiomatic, like the structure/function words in English) and then materializing the content, as well as refining the structures. E.g. I can say to a non-programmer that 'classes contain methods' and they kind of get the structure without knowing the content. In my mind this is represented as a graph, where the 'contains' relationship is an edge that connects two 'content nodes'. [something called class] --(contains)-> [something called method] If I follow up with 'methods contain code', they can reason that classes indirectly contain code, without even knowing what these things actually mean! So 'contains' is kind of a universal concept - it applies to abstract content and physical content in a similar way. Another universal connection is 'abstraction of', this implies one node (the abstract thing) is related to other nodes (the concrete things) in a specific way. Maybe structures can be made composable, and we can operate on graphs structurally, without knowing what the content means? While another operation might eventually figure out what the content means. The main assumption here is my thoughts are organized as graphs, where connections are both universal also domain specific but of few kinds. Can I talk to the computer in terms of such graphs? The second idea is: I want to combine high level concepts and strategies from from somewhat different domains. E.g. if I know different strategies for 'distributing things into bins' (consistent hashing, sharding, etc.), I invoke this 'idea' manually whenever I have see a situation which looks like 'distribute things into bins' and make a choice - irrespective of scale. Can I get the computer to do this for me instead? So the final thing here is to get to something like this: I take an idea (i.e. a node in a graph) from the distributed computing domain, merge it with a definition (another node) of a computation I created (e.g. persistence strategies), and have the computer offer options on how to distribute that computation (i.e. 'distributed persistence strategies'). Then I can make choices and combine it with a 'convert idea to machine code' strategy and generate a program. This is all a bit abstract at this point, but I'm also trying to find where this overlaps with prior art.

scroot 9y ago
> The main assumption here is my thoughts are organized as graphs Herbert Simon talks a lot about this in Sciences of the Artificial. It turns out most of human thinking is just lists. I'm not sure if that still stands in the field of psychology (my version of the book is pretty old, from the 80s). There's a good book (a little dense though) that might help with the more abstract thinking in the direction you're going. It's called "Human Machine Reconfigurations" and it's one of the more clever books I've come across on human machine interaction, written by an anthropologist/sociologist who also worked at PARC. So often the human part is what gets lost here.
- shalabhc 9y ago
  Thanks for the references! Sciences of the Artificial is already on my list. > The main assumption here is my thoughts are organized as graphs I realize this would be better phrased as "the information I'm trying to communicate is organized as graphs'.
alankay1 9y ago
A clarifying comment here. When one thinks in terms of what I called objects ca 1966, one is talking about entities that from the outside are identical to what we think of as computers (and this means not just sending messages and getting outputs, but that we don't get to look inside with our messages, and our messages don't get to command, unless whatever is going on in the interior of the computer has decided to allow. So from the outside, there are no imperatives, only requests and questions. Another way to look at this is that an object/computer is a kind of "server" (I worry to use this term because it also has "pop" meanings, but it's a good term.) This is sometimes called "total encapsulation". From this standpoint, we don't know what's inside. Could be just hardware. Could be variables and methods. Could be some form of ontology. Or mix and match. This is the meaning of computers on a network, especially large worldwide ones. The basic idea of "objects" is that what is absolutely needed for doing things at large scale, can be supplied in non-complex terms for also doing the small scale things that used to be done with data structures and procedures. Secondarily, some of the problems of data structures and procedures at any scale can be done away with by going to the "universal servers in systems" ideas. Similarly, what we have to do for critical "data structures" -- such as large scalings, "atomic transactions", versions, redundancy, distribution, backup, and "procedural fields" (such as the attribute "age") are all more easily and cleanly dealt with using the idea of "objects". One of the ways of looking at what happened in programming is that many if not most of the naive ways to deal with things when computers were really small did not scale up, but most programmers wanted to stay with the original methods, and they taught next gen programmers the original methods, and created large fragile bodies of legacy code that requires experts in the old methods to maintain, fix, extend ...