As mentioned, the reactivity makes this interesting to me. The amount of reactivity required for a project like LightTable is pretty ambitious, which we don't really see in most Lisp object systems (or any object systems for that matter).
> So what is the thing we want to compose if it's not the state? It's the reactions that objects have when events flow across the system. What tends to define variation in evented applications isn't the state of objects themselves, but how they react to certain messages. Given that, we want to be able to compose these reactions to create new versions of the same object. ... Behaviors are a way of creating bite-sized, reusable reactions to messages.
Then a comparison with the conventional approach:
> The way events are traditionally done in most modern platforms, you end up with hidden collections of listeners that contain nameless functions. This hides a vital bit of information - how do you know what's going to happen at runtime and how would you change that? ... By comparison, behaviors carry more information and are bound at call time. We can freely modify their reactions at runtime just by replacing the map in the LT data structure. And if we ever want to know what an object is going to do, we just take a look at that object's set of bound behaviors.
Finally, he talks about tagging, which might seem unrelated, but then I also adopted a similar in my own reactive object system [1] for simlar reasons: I needed a way to externally abstract over objects to get them to behave in similar ways (and ya, I did dynamic mixins too, this is a fun field).
That does not sound 'unique'. reusable actions to messages in Flavors are called methods and the reuse is done via Mixins and Method Combinations.
In Lisp you won't use 'nameless' functions. Typically one uses symbols, which are late bound to functions. Thus the symbol table is the map we can modify. In a meta-object-based object system like CLOS, generic functions are mapped to symbols and they have 'maps' of methods which will be combined at runtime.
The Xerox PARC researchers who defined CLOS worked a lot on the problems (mixins, active values, open implementations, meta-objects in software, ...).
Nothing is truly new under the sun. Perhaps I should have used the word novel and interesting rather than unique. You've also reminded me of Gabriel's most recent Onward essay:
I think Gabriel misidentifies this as a delta between science and engineering, but I think its more about the diff between communities. That we use different terminology, different sources, we have completely different underlying cultures. And you have to admit, the CLOS community is pretty unique, anyone looking from the outside is bound to have a very different frame of reference.
I've gone through as much CLOS work as I could, mixins inspired by an ice cream shop, active values (which are really just properties with custom get/set methods today) can serve as a nucleus for reactive programming but are not very sophisticated in managing change propagation (I think FRP signals are better, but you can clearly see the relationships). There is a lot there, but its not the end all of everything, their is some honest innovation going on here.
