4 ms·

> I think something based on agents that create loosely coupled systems where it easier to expand and replace parts would be a better place to look for a future

> I think something based on agents that create loosely coupled systems where it easier to expand and replace parts would be a better place to look for a future programming language. +1 A different question would be - what would a Smalltalk like system look like 'in the large'? (There was the Croquet project that was a live distributed environment so there has been some work done here already.) It seems the hallmark of Smalltalk was late binding so perhaps the core model can be extrapolated to a loosely coupled distributed system?

protomyth 9y ago
I've seen one large Smalltalk project, and it seems like it evolved into a tightly coupled group of classes. It looked really hard about reasoning about any changes since the dependencies were pretty high. I think if you went with clusters of VMs talking to each other you could probably do a pretty good job. I do wonder if the work at Yale on Linda[1] & Tuple Spaces[2][3] would have been more popular when it was introduced in Java[4] then people would have reasoned a bit differently on big systems. Going the CORBA[5] route always seemed to generate really problematic systems. The again, I really thought it would be cool to have people program in Occam[6] just to force some thinking about organization of programs. 1) https://en.wikipedia.org/wiki/Linda_(coordination_language) https://en.wikipedia.org/wiki/Linda_(coordination_language) 2) https://en.wikipedia.org/wiki/Tuple_space https://en.wikipedia.org/wiki/Tuple_space 3) https://books.google.com/books/about/Mirror_Worlds.html?id=jh2U379fq18C https://books.google.com/books/about/Mirror_Worlds.html?id=j... 4) https://www.javaworld.com/article/2076849/core-java/jini-technology--out-of-the-box.html https://www.javaworld.com/article/2076849/core-java/jini-tec... 5) http://www.corba.org/ http://www.corba.org/ 6) https://www.eg.bucknell.edu/~cs366/occam.pdf https://www.eg.bucknell.edu/~cs366/occam.pdf [PDF]
- shalabhc 9y ago
  Right - I think good ideas in Smalltalk are messaging (~actors) and the liveness. But the usual ST model is too 'flat' - all objects and classes live in the same space. This could be extended such that each object is a space in itself, with it's own inner objects - this model can then recursively scale up or down to multiple levels and also work for large systems. > work at Yale on Linda[1] & Tuple Spaces Ah, I see what you mean by loosely coupled. Yes, Linda is neat and if we think about objects/messaging with nested spaces, then each space can have its own form of messaging (could use tuple spaces, for instance). Also, I really like the cluster of VMs idea because you can then implement various kinds of cluster wide virtualizations on it (Croquet did this with Squeak VMs). I do think that cluster wide virtualization is the future of large programmable systems. We've built up some abstractions that work 'in the small' - we don't have to write assembly or do register allocation, but most 'languages' still limit you to think about what goes in within one Unix process, a very small part of the system. Whole system programming abstraction aren't really there yet.
  - protomyth 9y ago
    > But the usual ST model is too 'flat' - all objects and classes live in the same space. Yeah, but I think its more a problem with the original everything is an object concept. I've thought about it a lot, and keep coming back to Animal Farm[1] paraphrased as "All objects are equal but some objects are more equal than others." We create objects that really do things and value objects, but it takes time to examine a program and figure out the structure of the objects. Telling the doers (often name Agent or Manager) is a pain. Its not implicit in the programming language. > Yes, Linda is neat and if we think about objects/messaging with nested spaces, then each space can have its own form of messaging (could use tuple spaces, for instance). My thoughts on it are that you could really use the tuple spaces as the VM boundary (communications between VMs is the tuple space). Plus, the tuple space provides an interesting way to decouple logic and actually replace agents in a running program. Freeze the queries to a tuple space, replace the agent waiting on the tuple space, then unfreeze the tuple space. I think building a language and patterns to not only allow maintenance but also facilitate program upgrades would be very helpful. Not to mention testing of agents outside the whole of the program. A test bench where you can load an agent, connect it to a tuple space, and then run a ton of data through it to perform units tests would be very interesting. 1) https://en.wikipedia.org/wiki/Animal_Farm https://en.wikipedia.org/wiki/Animal_Farm
    - shalabhc 9y ago
      > We create objects that really do things and value objects, but it takes time to examine a program and figure out the structure of the objects. I agree with this too. I do think there is another layer of organization needed, which can be inspected to see the high level structure of the system - which objects form which part of the interconnected graph and which objects are passed around as messages, etc. I don't think everything-is-an-object needs to be changed though. An old attempt at layering another organization on top of objects is in the PIE papers: http://esug.org/data/HistoricalDocuments/PIE/PIE%20four%20reports.pdf http://esug.org/data/HistoricalDocuments/PIE/PIE%20four%20re... > My thoughts on it are that you could really use the tuple spaces as the VM boundary (communications between VMs is the tuple space). Oh I see, interesting. The 'freeze queries, update, resume' ideas sounds very useful, as similar patterns are often re-implemented many times over by various distributed databases. Might as well make it a standard feature of the system. One question is why only apply this to VM boundaries? Could this be applied to smaller scale (e.g. between smaller object clusters within one VM?). Applying this with finer granularity might let us update a single object or method only. The 'freeze' idea seems to fall into the managed time concept. Some interesting work in this area is Virtual Time by David Jefferson - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134.6637&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134... - and also NAMOS by David Reed.
- shalabhc 9y ago
  Forgot to mention some related project which falls into the 'clusters of VMs' running actors idea and might be interesting: https://dotnet.github.io/orleans/ https://dotnet.github.io/orleans/ and https://github.com/SpaceTime-IoT/erleans https://github.com/SpaceTime-IoT/erleans

protomyth 9y ago

I've seen one large Smalltalk project, and it seems like it evolved into a tightly coupled group of classes. It looked really hard about reasoning about any changes since the dependencies were pretty high. I think if you went with clusters of VMs talking to each other you could probably do a pretty good job. I do wonder if the work at Yale on Linda[1] & Tuple Spaces[2][3] would have been more popular when it was introduced in Java[4] then people would have reasoned a bit differently on big systems. Going the CORBA[5] route always seemed to generate really problematic systems. The again, I really thought it would be cool to have people program in Occam[6] just to force some thinking about organization of programs. 1) https://en.wikipedia.org/wiki/Linda_(coordination_language) https://en.wikipedia.org/wiki/Linda_(coordination_language) 2) https://en.wikipedia.org/wiki/Tuple_space https://en.wikipedia.org/wiki/Tuple_space 3) https://books.google.com/books/about/Mirror_Worlds.html?id=jh2U379fq18C https://books.google.com/books/about/Mirror_Worlds.html?id=j... 4) https://www.javaworld.com/article/2076849/core-java/jini-technology--out-of-the-box.html https://www.javaworld.com/article/2076849/core-java/jini-tec... 5) http://www.corba.org/ http://www.corba.org/ 6) https://www.eg.bucknell.edu/~cs366/occam.pdf https://www.eg.bucknell.edu/~cs366/occam.pdf [PDF]

shalabhc 9y ago
Right - I think good ideas in Smalltalk are messaging (~actors) and the liveness. But the usual ST model is too 'flat' - all objects and classes live in the same space. This could be extended such that each object is a space in itself, with it's own inner objects - this model can then recursively scale up or down to multiple levels and also work for large systems. > work at Yale on Linda[1] & Tuple Spaces Ah, I see what you mean by loosely coupled. Yes, Linda is neat and if we think about objects/messaging with nested spaces, then each space can have its own form of messaging (could use tuple spaces, for instance). Also, I really like the cluster of VMs idea because you can then implement various kinds of cluster wide virtualizations on it (Croquet did this with Squeak VMs). I do think that cluster wide virtualization is the future of large programmable systems. We've built up some abstractions that work 'in the small' - we don't have to write assembly or do register allocation, but most 'languages' still limit you to think about what goes in within one Unix process, a very small part of the system. Whole system programming abstraction aren't really there yet.
- protomyth 9y ago
  > But the usual ST model is too 'flat' - all objects and classes live in the same space. Yeah, but I think its more a problem with the original everything is an object concept. I've thought about it a lot, and keep coming back to Animal Farm[1] paraphrased as "All objects are equal but some objects are more equal than others." We create objects that really do things and value objects, but it takes time to examine a program and figure out the structure of the objects. Telling the doers (often name Agent or Manager) is a pain. Its not implicit in the programming language. > Yes, Linda is neat and if we think about objects/messaging with nested spaces, then each space can have its own form of messaging (could use tuple spaces, for instance). My thoughts on it are that you could really use the tuple spaces as the VM boundary (communications between VMs is the tuple space). Plus, the tuple space provides an interesting way to decouple logic and actually replace agents in a running program. Freeze the queries to a tuple space, replace the agent waiting on the tuple space, then unfreeze the tuple space. I think building a language and patterns to not only allow maintenance but also facilitate program upgrades would be very helpful. Not to mention testing of agents outside the whole of the program. A test bench where you can load an agent, connect it to a tuple space, and then run a ton of data through it to perform units tests would be very interesting. 1) https://en.wikipedia.org/wiki/Animal_Farm https://en.wikipedia.org/wiki/Animal_Farm
  - shalabhc 9y ago
    > We create objects that really do things and value objects, but it takes time to examine a program and figure out the structure of the objects. I agree with this too. I do think there is another layer of organization needed, which can be inspected to see the high level structure of the system - which objects form which part of the interconnected graph and which objects are passed around as messages, etc. I don't think everything-is-an-object needs to be changed though. An old attempt at layering another organization on top of objects is in the PIE papers: http://esug.org/data/HistoricalDocuments/PIE/PIE%20four%20reports.pdf http://esug.org/data/HistoricalDocuments/PIE/PIE%20four%20re... > My thoughts on it are that you could really use the tuple spaces as the VM boundary (communications between VMs is the tuple space). Oh I see, interesting. The 'freeze queries, update, resume' ideas sounds very useful, as similar patterns are often re-implemented many times over by various distributed databases. Might as well make it a standard feature of the system. One question is why only apply this to VM boundaries? Could this be applied to smaller scale (e.g. between smaller object clusters within one VM?). Applying this with finer granularity might let us update a single object or method only. The 'freeze' idea seems to fall into the managed time concept. Some interesting work in this area is Virtual Time by David Jefferson - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134.6637&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134... - and also NAMOS by David Reed.
shalabhc 9y ago
Forgot to mention some related project which falls into the 'clusters of VMs' running actors idea and might be interesting: https://dotnet.github.io/orleans/ https://dotnet.github.io/orleans/ and https://github.com/SpaceTime-IoT/erleans https://github.com/SpaceTime-IoT/erleans