Hacker News Reader

Comment by protomyth | Hacker News Reader

As much as I like Lisp or Smalltalk, I cannot help but wonder if they are really great in the large. Smalltalk has a pattern called Double Dispatch that makes sense but seems to tightly couple the classes. I keep looking at, of all things, the VBX market in the 90's and wonder why we don't have those type of components with current languages. 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.

View on HN

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

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?

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)

2) https://en.wikipedia.org/wiki/Tuple_space

3) https://books.google.com/books/about/Mirror_Worlds.html?id=j...

4) https://www.javaworld.com/article/2076849/core-java/jini-tec...

5) http://www.corba.org/

6) https://www.eg.bucknell.edu/~cs366/occam.pdf [PDF]

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.

> 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

> 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%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... - and also NAMOS by David Reed.

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/ and https://github.com/SpaceTime-IoT/erleans

I wonder if there is a future for Pharo Smalltalk as a user interface and coding environment that uses backend services written in other languages. Last week I saw Python matplotlib bindings for Pharo and as I played with this, I thought of interfaces to TensorFlow, ML services at AWS, GCP, and Azure, etc. This idea probably does not make sense, but the idea hit me.

EDIT: like a replacement for Jupyter, but more capable.

Amber [1] is a Smalltalk that you use to develop in a Web Browser, but which will compile for you to JS on the back end.

[1] http://www.amber-lang.net/

Technically, it should be possible to build a Pharo / Squeak environment in a dynamic language like Python or Ruby. I generally see it as more a cultural issue. Pharo (and Smalltalks in general) are very productive environments, but they live on the concept of live objects (Smalltalk in the form of an image-based development environment). Given the love of text editors and Unix-style file development, I doubt there would be a move in that direction.

Are you secretly promoting Elixir/Erlang, or am I misreading what you mean with 'agents' in this case?

Down that path, but I'm just not sure Erlang is enough. I might be a bit infected by the promise of Telescript[1] or a paper[2]. RPC over HTTP (in one or more of its forms) won over mobile code, but I think the concept of software agents actually has a bigger win in the building of complex systems that can be reasoned about in the small as well as the large. I also think that the ability to replace software agents in a large system would be easier than refactoring / replacing objects.

1) https://en.wikipedia.org/wiki/Telescript_(programming_langua...

2) http://robotics.stanford.edu/~shoham/www%20papers/AgentOrien... from http://robotics.stanford.edu/~shoham/

I'd love to hear your thoughts on what you'd like to see beyond Erlang. I'm new to Elixir/Erlang, so very curious to see it in a broader perspective.

I love Erlang and their attitude about keeping systems running. Plus, the syntax gets a bad rap when its just different. Sadly, the process and state models are different from what really interests me in agents.

Which part interests you about agents?

I'm having a hard time writing up a complete answer, and will probably someday write an actual article, but I think the key for me is loose coupling of functionality and mobile code being a very interesting way to scale up a server farm. The whole thought of combining agents and tuple spaces into a system seems a lot closer to true reuse in software than objects has been. I think an agent programming language, a good speech act based communication language instead of the typical API, decent data types, and tuple spaces would make for a heck of a nice programming environment. I've had a hobby project for a long time to bring those elements together but I am still in the learning phase.

Look up Telescript or Obliq languages for interesting stuff that was agent-oriented.

I mentioned Telescript in my reply[1] to mercer[2]. Obliq is pretty cool (the implementation is really interesting), but not the type of agents I want.

1) https://news.ycombinator.com/item?id=16408262

2) https://news.ycombinator.com/item?id=16408159

Reply on news.ycombinator.com