Dan Ingalls and Allen Wirfs-Brock: On Smalltalk, Lively Kernel, Javascript and Programming the Inter

edit: found low resolution copy. Thanks C.

Great discussion. Having assimilated the recent group of language discussions with people like Dan, Allen, Erik, Giland and others; it seems a natural commonality has appeared. All the pieces exist that we need, but we just need a good chef to mix the cake.

It seems the problem domain is:
1) Many core, threads, and locking problem.
2) Shared state problem.
3) Local/remote message passing arch.

It seems to follow that the "ingredients" of next lang arch need to be:
1) Read-only message based arch at core.
2) Message loop as primary in/out of all classes (e.g Erlang).
3) Local model same as remote model so distributed apps are same (i.e. Volta like).
4) A dedication to above in keeping the rules and not allowing leakage.

Thought experiment:
1) All objects, and messages, are read-only external to the owner. So if I pass "this" (class1) as a message to class2, a copy of class1 is made (by the system) and passed to the class2 in-queue (by the system). Class2 can not set state in original class1 as it has only a local copy. All this is enforced by the runtime. class2 is the only class that can get this message.  Multicast is handled with multiple copies of class1 sent to many classes. Class1 now becomes local state of class2 as long as it wants to keep it. The only way to change state is local - by handling messages.

2) Each class message loop is single-threaded. So locks are mostly gone. Classes can be created on separate threads for concurrency. Coordination is done via message passing and/or some root controller/state class.

3) All In-Messages are handled by a message loop in the class (ala windows message loop). Something like CCR and/or Linq message popping is used to handle messages processed by type or some predicate using lambda functions. Something like setting properties just become a message handled by the class, but publicly looks like a simple property setter.

4) Remote access becomes same pattern as local access - no surface difference. The arch handled all the comm goo below (ala Volta).

Features:
1) All objects become services handling messages.
2) Remoting is as simple as local in-proc.
3) Shared state is mostly solved.
4) Very parallel by design.
5) Async streaming and pipelining become very natural.
6) Very dynamic in nature. Objects can be removed and replaced in the system at runtime because of the loose message passing and queue model.
7) Events are replaced because not needed. Same behavior is handled by async messages.

-
W

esoteric wrote:

Cozy interesting discussion. Here's a presentation of Lively Kernel: http://www.youtube.com/watch?v=gGw09RZjQf8