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

Sign in to queue

The Discussion

  • User profile image
    Hmmm... I recall the Amiga, Blitter and Cooper!

  • User profile image

    edit: found low resolution copy. Thanks C.

  • User profile image

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

    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.


  • User profile image
    Cozy interesting discussion. Here's a presentation of Lively Kernel: http://www.youtube.com/watch?v=gGw09RZjQf8
  • User profile image
    esoteric wrote:
    Cozy interesting discussion. Here's a presentation of Lively Kernel: http://www.youtube.com/watch?v=gGw09RZjQf8

    Or you can play with it live here.
  • User profile image
    Excellent Talk, Good stuff but i tend to agree what charles said, developers like real programming languages not the dynamic sort of......

    Lets see where this all goes in to future...

    Learn't most important thing from video was use :-https://www.live.com 

    Thx, for all the cool stuff...Smiley
  • User profile image
    Ah yes... Javascript's ubiquity is fantastic, runs on every browser... except on IE it seems (at least for the moment)

Add Your 2 Cents